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.
<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!
<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
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>
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