Flea86 has joined ##openfpga
GenTooMan has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 246 seconds]
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
dj_pi has joined ##openfpga
carl0s has quit [Ping timeout: 256 seconds]
GenTooMan has quit [Quit: Leaving]
dj_pi has quit [Ping timeout: 246 seconds]
_whitelogger has joined ##openfpga
s_frit_ has joined ##openfpga
pie__ has joined ##openfpga
s_frit has quit [Ping timeout: 246 seconds]
pie___ has quit [Ping timeout: 250 seconds]
futarisIRCcloud has joined ##openfpga
s_frit_ has quit []
s_frit has joined ##openfpga
emeb_mac has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
scrts has quit [Ping timeout: 244 seconds]
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
emeb_mac has quit [Quit: Leaving.]
scrts has joined ##openfpga
Thorn has quit [Ping timeout: 245 seconds]
scrts has quit [Ping timeout: 272 seconds]
<_whitenotifier-9> [whitequark/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fh5FL
<_whitenotifier-9> [whitequark/Glasgow] whitequark a79439c - applet.audio_output: use a ΣΔ DAC instead.
<_whitenotifier-9> [whitequark/Glasgow] whitequark f35ce43 - applet.audio_output: refactor and add 16-bit sample format support.
<kbeckmann> tnt: that's neat! glad to see that you are able to receive something that looks meaningful, seems i didn't mess up the rx part too much :). that approach sounds sane, to capture raw samples and do the processing offline and get it right.
<_whitenotifier-9> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/494757228?utm_source=github_status&utm_medium=notification
m4ssi has joined ##openfpga
<tnt> kbeckmann: yup, didn't get a chance to play with a lot of the settings yet, and the i2c is bitbanged from the host, but that's a starts. Next step will be (1) validate the IO capture timing (atm, I just assumed 'heh, it'll be good enough'), (2) implement control logic to read/write spi registers on the fpga itself (3) DSP on the fpga to turn ΔΣ input into 8 bits samples.
Thorn has joined ##openfpga
scrts has joined ##openfpga
<kbeckmann> awesome. yeah you can come pretty far with just bitbanging and not reading anything with the i2c bridge and spi interface.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<keesj> tnt: cool.. on the SX1257... I did not know there where ready made pmods for this
<kbeckmann> keesj: i built one but it is in the early bringup phase, need to fix a few things for rev2. let me know if you want one later!
<keesj> it sounds interesting indeed
<keesj> I also fancy some hand assembly
<keesj> do you have a project page/ blog?
<keesj> tnt: thanks
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
<marcan> do you know sigma-delta encoding? it's literally less code and better quality
rohitksingh_work has quit [Read error: Connection reset by peer]
<marcan> (moves the noise to higher frequencies more effectively than the reversed-PWM thing)
<tnt> Still have to check exactly what the comment "For benchmarking purposes only -- don't use this for an actual design." means and how to fix it and how spectrum compares to a single order design.
<marcan> basic first order is literally just
<marcan> {output, acc} <= acc + sample;
<marcan> one line of verilog, and it works much better
<tnt> I know, that's what I'm using now.
<marcan> that was for ZipCPU
<tnt> oh, sorry nm.
renze has quit [Quit: Spaceserver reboot?!]
<ZipCPU> Thanks, marcan!
Finde has quit [Ping timeout: 246 seconds]
Finde has joined ##openfpga
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
LAK132 has joined ##openfpga
<LAK132> is it at all possible to get nmigen+yosys to produce `assign thing = 1'b0;` instead of `always @* begin \$next\thing = 1'b0; end assign thing = \$next\thing;`?
<q3k> why?
<LAK132> No particular reason, just curious
<kbeckmann> Are those two things equivalent? I'm not very good at verilog and this confuses me a little bit.
<LAK132> I'm not sure either
<LAK132> The original verilog was for a TinyFPGA BX, in the top it's got `assign USBPU = 0;`
<LAK132> I'm trying to replicate this in nMigen
tmeissner has joined ##openfpga
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 258 seconds]
emeb has joined ##openfpga
s_frit has quit [Read error: Connection reset by peer]
<kbeckmann> or are they "basically the same" and yosys will generate the same output?
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<LAK132> that's the big question!
<daveshah> They are exactly the same thing
<somlo> "always @*" appears to be what became "always_comb" in System Verilog, which, according to the digital design class I took a few years ago is just a cleaner way to implement a "complex" assign statement
<kbeckmann> alright cool. so assign foo = bar ? 1 : 0; is the same as always @* begin if (foo) bar = 1; else bar = 0; end... i think i have had some issues when doing this earlier but i probably just make some other mistake.
<kbeckmann> uhh i mixed foo and bar in the second part but you get the idea.
<daveshah> No, that case isn't the same
<daveshah> ?: and if have different semantics when the condition is 1'bx
<kbeckmann> oh right, that makes sense. i always tend to forget that we have more han just 1 and 0. thanks.
<daveshah> s ? a : b will result in Xs if s is 1'bx unless a and b are the same (then it will result in their value)
<daveshah> if(s) will be evaluated as if s is false if s is 1'bx
<kbeckmann> thanks for clearing this up!
<somlo> but "assign foo = bar ? 1 : 0" *will* be the same as "always @* begin foo = bar ? 1 : 0; end" :)
<daveshah> yes
<kbeckmann> that makes sense :)
<LAK132> good to know
LAK132 has quit [Ping timeout: 256 seconds]
renze has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
emeb has quit [Read error: Connection reset by peer]
emeb has joined ##openfpga
tmeissner has quit [Ping timeout: 255 seconds]
mumptai has joined ##openfpga
lain has quit [Ping timeout: 246 seconds]
<azonenberg> daveshah: i dont pay much attention to what happens when you calculate with an X
<azonenberg> in my world, if you see an x you have a bug
<azonenberg> abort the sim, find where it came from
<azonenberg> what happens after that is presumed invalid
<whitequark> daveshah: kbeckmann: somlo: in nmigen there is no x
<whitequark> so, unless you put x into the design, the difference does not matter
<azonenberg> whitequark: so are multiple drivers impossible?
<azonenberg> (that's the main place i see x's)
<azonenberg> that, and uninitialized values
<whitequark> azonenberg: correct
<azonenberg> do you mandate init too?
<whitequark> yes
<azonenberg> i guess this is fpga-targeted exclusively? and only some fpgas?
<whitequark> I think all FPGAs can init to zero
<azonenberg> eh, at least one microsemi family i know of has bram data optional
<whitequark> and then Yosys takes care of init to nonzero
<whitequark> no, not bram
<azonenberg> and there's not enough on chip flash to initialize all the bram
<azonenberg> you can initialize any N brams but you have to leave some uninit
<azonenberg> so if you read a bram address you have not yet written
<azonenberg> what do you get?
<azonenberg> in a xilinx part i think zero, but in simulation or one of those microsemi parts it's undefined
lain has joined ##openfpga
<whitequark> oh i see what you mean
<whitequark> hmm
<daveshah> The main time I've worried about X propogation is modelling FPGA primitives with disconnected inputs
<azonenberg> Making that a requirement also makes nmigen unusable for asic
<azonenberg> unless you want to mandate a single global POR of some sort
<whitequark> that's the idea
<azonenberg> DFFs with reset also take up more area
<azonenberg> Which can be an issue in particularly dense spaces
<azonenberg> oh and even then, you still sometimes see X's in gate-level simulation if you have timing violations
<azonenberg> or impossible states
<whitequark> mmm, you're right, I'll need to address this more clearly
<azonenberg> what do you get if you have a differential input buffer with both legs low?
<azonenberg> or a latch with S/R asserted simultaneously?
<whitequark> the main point is to have reset opt-out and not opt-in (you can have reset-less DFFs, e.g. in synchronizers), and to eliminate multiple drivers
<whitequark> a more correct way to say it would be,
<whitequark> if you use nmigen in the easy way, you won't get any X
<whitequark> (so long as you don't feed one in)
<daveshah> Another common case is a bidirectional memory DQ bus or the like when neither end is driving
<azonenberg> Eliminating multiple drivers seems doable as long as you also prohibit internal tristates
<azonenberg> daveshah: that's Z not X
<azonenberg> although if you feed a gate with a Z, i think you should get X out
<whitequark> nmigen does not have internal tristates
<daveshah> whitequark: good riddance :)
<azonenberg> whitequark: So no shared bus fabrics on chip
<azonenberg> Not necessarily a bad thing, but would make a gate-accurate model of (say) the coolrunner impossible
<whitequark> azonenberg: you could, of course, instantiate gates
<whitequark> this counts as "feeding X in"
<whitequark> the point being that nmigen does a very safe subset of digital logic and you have to opt out of it
<azonenberg> Yeah, that much i agree with (safe by default)
<whitequark> unlike sb I do not have a problem with x by itself, just like UB in C/C++
<azonenberg> But you have to allow the low level stuff sometimes to be useful, and you have to consider what happens to X when that happens
<whitequark> I have a problem with pervasive UB
<whitequark> I agree
<azonenberg> (just like unsafe code in managed languages being necessary for MMIO etc)
<whitequark> it is a general goal to have well defined rules for X interaction from outside sources
<whitequark> but without compromising the basic goals
<azonenberg> honestly i would love a simulator mode targeting FPGA logic
<azonenberg> that calls $finish any time an x is generated
<azonenberg> and lets you investigate how it happened
<azonenberg> Obviously this wouldn't fly in asic, or even for all fpga designs
<azonenberg> but it'd be a nice default for fpga rtl
<tnt> azonenberg: heh, I have x all over my design usually because I often have plenty of things that don't have reset because they don't need to. But of course I ensure that control signals and 'valid' flags etc are always valid and they make sure those 'x' don't actually have any actual impact anywhere it matters.
m4ssi has quit [Remote host closed the connection]
<azonenberg> I do that sort of design in asic, because a dff is smaller than a dffr
<azonenberg> but in fpga the resets are free so i use them on everything
<azonenberg> it all depends on what the module is targeting
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
AlexDaniel-old[m has quit [Quit: removing from IRC because user idle on matrix for 30+ days]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<_whitenotifier-9> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhdmj
<_whitenotifier-9> [whitequark/Glasgow] whitequark 8053da7 - applet.audio_output: add --loop.
<_whitenotifier-9> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhdYe
<_whitenotifier-9> [whitequark/Glasgow] whitequark e3e6b90 - applet.audio_output: add --loop.
<_whitenotifier-9> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/whitequark/Glasgow/builds/495129073?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/495129362?utm_source=github_status&utm_medium=notification
<_whitenotifier-9> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhdYk
<_whitenotifier-9> [whitequark/Glasgow] whitequark 3d317ae - applet.audio_output: add --loop.
<_whitenotifier-9> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/495132239?utm_source=github_status&utm_medium=notification
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
Flea86 has joined ##openfpga
mumptai has quit [Quit: Verlassend]
<sorear> simulation is not synthesis, so I don't 100% follow why not having 4-state simulation semantics prevents you from synthesizing using standard cell libraries
<whitequark> it doesn't
<whitequark> you just have a sim-syn mismatch
<whitequark> or equivalently you have to artificially restrict the state space
<whitequark> "guarantee POR"
<sorear> 'x is a conservative approximation of physical reality anyway, kinda like interval arithmetic
<sorear> it's not True
<whitequark> oh?
<sorear> a bit, stored in a register for long enough to lose metastability, is either 1 or 0
<whitequark> oh yeah
<sorear> if you pass 'x through several registers and then XOR with itself, you'll get 'x in a four-state simulator and '0 in physics
<whitequark> so you want something like llvm's poison and not 'x
<daveshah> sorear: I'm pretty sure I've seen this as a genuine issue somewhere
<sorear> the berkeley people have a long-term problem with "core mis-speculates a branch into uninitialized memory, the two-state simulation and the test chip work correctly because the nonsense result is flushed from the pipeline, the four-state simulation fails because all the control signals become 'x"
<daveshah> A CPU with registers starting at X, and some init code XORing registers with themselves to clear
<sorear> or if you do an operation that takes a non-deterministic number of cycles using X data
<show1> azonenberg: 'in fpga the resets are free' ...this is not true
<daveshah> depends on the FPGA
<sorear> the classic Arm text for those who haven't seen it: http://infocenter.arm.com/help/topic/com.arm.doc.arp0009a/Verilog_X_Bugs.pdf
<daveshah> ECP5 has one free reset because GSR is user accessible (and can even be synchronous)
<show1> maybe they don't impact the size of the dff itself (because it is already there) but they use routing ressources
<daveshah> well, if they are on a global network because you need enough initialised DFFs then they don't
<daveshah> on some architectures like iCE40, packing FFs with and without a reset in the same tile isn't possible so it's better for them all to have a reset
<sorear> isn't the GSR a dedicated global network that can't be used for anything else anyway
<daveshah> yeah
<sorear> it's not "free" in the sense that you had to pay for the process steps, but once you have the chip the marginal cost of using it is zero
<show1> i like to reference the wp272 of xilinx concerning resets (altough it's some years old)
<daveshah> well, it's already there to ensure that FFs start in a determinstic state
<show1> i tend to only use resets in fpga designs where necessary and not just use them 'because they are free'
<azonenberg> sorear, show1: i mean POR
<azonenberg> POR in FPGA is free, in most cases
<azonenberg> i avoid using runtime resets in FPGA unless unavoidable
<sorear> "GSR" in ECP5 is part of the POR mechanism
<sorear> there's a primitive you can instantiate to drive GSR again post-POR
<show1> azonenberg: okay, now i'm with you ;)
<sorear> but it's mostly POR
<azonenberg> Therefore there's no reason in *most* FPGAs not to put an "initial" value for every dff
<azonenberg> the exception being certain microsemi bram iirc
<daveshah> ECP5 does have one catch that initial values have to match set/reset value
<sorear> bram data isn't dffs ?
<daveshah> Diamond will discard them with a warning if they don't
<azonenberg> sorear: one fpga family i know of had on die config memory
<azonenberg> that was enough to store all lut/routing config
<daveshah> Another catch - BRAM output ports don't have an initial value
<azonenberg> and you could initialize X percent of brams
<azonenberg> daveshah: in xilinx land they do
<daveshah> oh interesting
<daveshah> azonenberg: machxo parts require you to use bitstream compression because they don't have enough on-die flash even for lut/routing
<azonenberg> daveshah: INIT_A and INIT_B parameters to xilinx bram parameters define the startup values of the output latches
<daveshah> in theory I think a pathological design with large amounts of random data in LUTs and BRAM might not fit
<azonenberg> daveshah: interesting
<azonenberg> daveshah: basically those parts had optional frames for bram
<azonenberg> they had enough config for x percent to be initialized
<azonenberg> the rest you had to start as X and load from fabric
<daveshah> you could end up in the same situation with an ecp5 and undersized spi flash, as bram are initialised one by one in the bitstream
m_w has joined ##openfpga
<daveshah> > Lattice design software uses proprietary compression technology to compress bit-streams for use in MachXO2 devices. Use of this technology allows Lattice to provide a lower cost solution. In the unlikely event that this technology is unable to compress bitstreams to fit into the amount of on-chip Flash memory, there are a variety of techniques that can be utilized to allow the bitstream to fit in the on-chip Flash
<daveshah> memory. For more details, refer to TN1204, MachXO2 Programming and Configuration Usage Guide.
<whitequark> huh
<whitequark> 22:47 < daveshah> ECP5 does have one catch that initial values have to match set/reset value
<whitequark> in nmigen initial and reset value are one and same
<whitequark> which fixes this problem at the root
<whitequark> like, nmigen has a concept of "clock domain" and "reset"
<daveshah> One problem is that synthesis tools can infer a reset when you don't expect one
<whitequark> right, but that's a failure of the synthesis tool imo
<daveshah> e.g. q <= a ? b : 1'b0
<whitequark> if it infers something it better be legal
<whitequark> the same way you don't infer 5-LUTs on a 4-LUT arch
<daveshah> Once my PR is merged Yosys will deal with this correctly and not infer a reset if it would conflict with the initial value
<daveshah> Diamond infers a reset and warns about the ignored initial value
<daveshah> As an aside, there's a quirky mode of the ECP5 flipflops called preload (that the vendor tools never seem to use and barely even support), that could hypothetically be used to implement a non-constant initial value (and I've tested this on hardware)
<whitequark> huh
<daveshah> Preload causes set/reset (local or global) to load the "M" slice input into the flipflop
<daveshah> with async set/reset mode this can also be used to implement a latch, which the ecp5 don't officially support
pie__ has quit [Ping timeout: 250 seconds]
Bike has joined ##openfpga
<azonenberg> daveshah: i have this issue in vivado fwiw
<azonenberg> if you have an always @(posedge clk or negedge rst) block
<azonenberg> and if the if(!rst)block does not assign a value to something
<azonenberg> it will do weird things
<azonenberg> like, it'll think you have a S and R on the same dff