genii has quit [Remote host closed the connection]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
Bike has joined ##openfpga
<adamgreig> looks like my spi issues were SI or other hardware issue after all. fixed a cold joint on a decoupling cap and reflowed the tiny flash chip and now it works fine. go figure.
<adamgreig> programmer is all working now... 0.8s to program fpga, 2.5s to program flash with one image, using hacky python script on the desktop
<adamgreig> could be worse
<adamgreig> 2.5s includes readback verification
<azonenberg> nice
<azonenberg> incidentally, this is one of the reasons i want to have glscopeclient supporting fancy measurements, eye patterns, etc on all hardware
<azonenberg> SI problems happen at all speeds
<azonenberg> So even with a cheap 2-channel siglent you'd be able to do look at MOSI wrt SCK and see how it looks
<adamgreig> makes sense
<adamgreig> would sure have been nicer than fiddling with it on the scope
lexano has quit [Ping timeout: 246 seconds]
vonnieda has joined ##openfpga
lexano has joined ##openfpga
cr1901_web has quit [Ping timeout: 256 seconds]
cr1901_modern1 has joined ##openfpga
futarisIRCcloud has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
flea86 has joined ##openfpga
Bike has quit [Quit: Lost terminal]
gsi_ has joined ##openfpga
balrog has quit [Quit: Bye]
gsi__ has quit [Ping timeout: 255 seconds]
balrog has joined ##openfpga
<TD-Linux> noice
<TD-Linux> adamgreig, I wonder what the best UI would be for windows users. is there a nice GUI for DFU or something
Bob_Dole has quit [Ping timeout: 252 seconds]
knielsen has quit [Ping timeout: 246 seconds]
jevinskie has joined ##openfpga
knielsen has joined ##openfpga
Bob_Dole has joined ##openfpga
<_whitenotifier-3> [Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (Nearly) - https://git.io/fhxmz
_whitenotifier-3 has joined ##openfpga
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
zng has quit [Read error: Connection reset by peer]
zng has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
rohitksingh_work has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
IanMalcolm has quit [Ping timeout: 252 seconds]
jevinskie has joined ##openfpga
IanMalcolm has joined ##openfpga
OmniMancer has joined ##openfpga
m_w has quit [Quit: Leaving]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 258 seconds]
m4ssi has joined ##openfpga
<cpresser> TD-Linux: not that I am aware of. I am using dfu for work stuff, and we always put some stupid gui wrapper around dfu-util
emeb_mac has quit [Ping timeout: 255 seconds]
Asu has joined ##openfpga
pie___ has quit [Ping timeout: 258 seconds]
unixb0y has quit [Ping timeout: 244 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 246 seconds]
ondrej3 has quit [Quit: Leaving]
ondrej3 has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
carl0s has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vonnieda has joined ##openfpga
genii has joined ##openfpga
rohitksingh has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
azonenberg_work has quit [Ping timeout: 246 seconds]
emeb has joined ##openfpga
ym has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
mumptai has joined ##openfpga
emeb_mac has joined ##openfpga
carl0s has quit [Quit: Page closed]
gnufan_home has joined ##openfpga
<anuejn> is there anything that can be done to help with machxo2 support in prjtrellis / nextpnr?
Laksen has joined ##openfpga
Dolu has quit [Ping timeout: 245 seconds]
jevinskie has joined ##openfpga
jevinskie has quit [Client Quit]
cr1901_web has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
rohitksingh has joined ##openfpga
<q3k> anuejn: hm
<q3k> anuejn: i vaguely remember someone working on this
<q3k> anuejn: but honestly don't remember who that was. cc daveshah ?
<tnt> I think cr1901_web ?
Dolu has joined ##openfpga
<tnt> and AndresNavarro82
<cr1901_web> anuejn: Is this MachXO2 stuff? It's ongoing, but prob until the end of May is not a good time to ask me about it. It'll be ready soon, I promise :P
* vonnieda is excited to hear this!
<tnt> Does yosys already have synth sypport for it ?
<cr1901_web> Most of the trellis stuff will work for it
steve|m_ is now known as steve|m
<emeb_mac> This morning I did some tweaks on my up5k design that added a 2nd clock output from the PLL which is running at 2x the rate of most of the rest of the system.
<emeb_mac> I use it in the video circuitry to allow interleaved access between the CPU and video DMA. Works fine.
<emeb_mac> Problem is that I'm getting timing violations from nextpnr on this new clock. Digging into the timing report I'm pretty sure it's a false path - it snakes around in the low speed clock domain and comes back to an input upstream of where it ought to go.
<emeb_mac> So question is: is there any way of declaring false paths?
<tnt> emeb_mac: pastebin ?
<daveshah> There's no false path support at the moment
<emeb_mac> path starts at the output of a RAM block, snakes back through the CPU and ends up at the address input of the same RAM block
<tnt> emeb_mac: is the verilog somewhere ?
<tnt> It ends at a fabric flip flow.
<emeb_mac> what's a "fabric flip flow"?
<tnt> -w+p
<emeb_mac> right - but it goes thru this net: Info:  3.7 38.5    Net uut.uvid.mem_addr[0]
<tnt> oh ... using the clk signal in logic itself ...
<tnt> not a good idea imho.
<emeb_mac> it's the lower speed clock
<tnt> yeah sure but still.
<emeb_mac> and it's synchronous
<tnt> I usually create a separate fabric signal independent of the clock.
<tnt> because edge of the 'fabric' signals happen "clock-to-out" after the actual clock edge
<tnt> just my experience ... keep clocks only feeding clock inputs and keep logic signal feeding logic.
mumptai has quit [Read error: Connection reset by peer]
<tnt> you can create a 'toggle' signal from the clk2x signal.
mumptai has joined ##openfpga
<emeb_mac> Yeah - I'm not super comfortable with this either, but that toggle signal would have to be synced to the lower speed clock.
<tnt> yeah, you release a 'reset' signal from the lower clock to make it have a known alignement.
<emeb_mac> could reclock the lower speed clock once I suppose, but that still violates the premise.
<tnt> it's a bit of "gymnastics" but it has served me well in the past.
<azonenberg_work> tnt: i've used the toggle signal approach in the past
<azonenberg_work> among other things, to determine phase relationship between a 1x and 2x clock
<azonenberg_work> so i could keep track of even/odd edges in the 2x domain
<emeb_mac> that's what I'm doing
<emeb_mac> using the odd/evens to interleave video/cpu access to memory
<emeb_mac> but that's working fine ATM and is likely not the reason for the long path.
<azonenberg_work> this was similar, double pumping a ram
GenTooMan has joined ##openfpga
<tnt> emeb_mac: I wouldn't be sure that it's not the problem ... somehow confusing the timing analysis that the clock signal feeds logic ...
<tnt> is the source for uram somewhere ?
<emeb_mac> tnt: fair point
<tnt> So your path ends at the 'hilo_sel' flip flop.
<tnt> So looks like a perfectly valid path to me actually.
<emeb_mac> what's your basis for that?
<tnt> For what ? that it ends at the flip flop ?
<emeb_mac> given that the path starts at the data output of that ram then loops back to the address input by going through the CPU core.
<emeb_mac> that's an async path that wouldn't ever actually be active in a working design.
<tnt> why ? I would assume that the current opcode can influence the next fetched address.
<tnt> doesn't really look crazy to me ...
<emeb_mac> but due to the interleaving the address on the next cycle would always come from the video system, not from the cu
<emeb_mac> cpu
rohitksingh has quit [Ping timeout: 246 seconds]
<emeb_mac> I guess my definition of "false path" is different from yours.
<tnt> emeb_mac: err ... your 'hold thing' is implemented using luts ... they're not glitch-less so in reality to be 100% safe the tool has to account that there might be a glitch at the half clock cycle.
<tnt> an so that path has to be able to stabilize in half a cycle.
<emeb_mac> I'll grant that hold mux is an ugly hack.
<emeb_mac> and probably not even needed since the data output just needs to meet setup time for the CPU input.
jevinskie has joined ##openfpga
<emeb_mac> getting rid of the async logic and just routing hld_dout straight to dout works fine and eliminates that violating path.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<emeb> tnt: thanks for the fresh perspective - eliminating the 'hold thing' and adding that proper clock/logic separation definitely "feels" better.
<emeb> I still have a timing violation in the clk_2x domain but it's not exactly the same.
jevinskie has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gnufan_home has quit [Quit: Leaving.]
gnufan_home has joined ##openfpga
gnufan_home has quit [Quit: Leaving.]
mumptai has quit [Quit: Verlassend]
Asu has quit [Quit: Konversation terminated!]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<emeb> Experimenting with some simple DSP in yosys/nextpnr - doing an NTSC colorburst involving an NCO to generate the color reference and a binary shift to adjust the saturation. Trying to use the Verilog arithmetic right shift operator and finding that it doesn't seem to preserve the sign bit. As a workaround just using concatenation.
<emeb> lol - nm. pebkac.
<TD-Linux> verilog promotion to unsigned claims another victim
<azonenberg_work> TD-Linux: personally in HDLs i assume everything is unsigned
<azonenberg_work> and explicitly sign extend with bit manipulations in the *very* rare situations when i want that
<TD-Linux> as a codec developer I assume everything is signed
<TD-Linux> unsigned numbers should be illegal
<azonenberg_work> lol
<emeb> heh
<azonenberg_work> meanwhile i get annoyed when i printf a byte with a negative value without casting to unsigned first
<TD-Linux> some of it is also a habit from C - ubsan only catches overflows on signed values.
<azonenberg_work> and it sign extends so i get a hex dump like "00 42 70 FFFFFFCD 2F 0A"
<TD-Linux> (thx rust)
<emeb> I fought with signed/unsigned stuff in verilog for years and it still bites me.
<emeb> VHDL is a lot more predictable.
<azonenberg_work> i'm used to bits staying the same
<TD-Linux> yeah that's more of a libc design mistake
<azonenberg_work> i guess we just work on different kinds of code
<azonenberg_work> because i'd say that probably 95% of the time i use a signed type it's just me being too lazy to type out "uint32_t"
<azonenberg_work> the value will never be negative but i don't need the extra bit of range
<azonenberg_work> in fact the lack of a proper uint32 type is one of my biggest gripes with java
<emeb> 90% of the stuff I do is DSP (audio, wireless comm,etc) so I depend heavily on true signed data.
<TD-Linux> azonenberg_work, yeah, because of the ubsan behavior, I highly recommend using signed types even if you don't need negative values
<TD-Linux> unless you intentionally need wrapping or really need that extra bit
<azonenberg_work> TD-Linux: see, i prefer to use unsigned types to prevent wrapping from being possible
<azonenberg_work> wrapping to negative*
<azonenberg_work> oh, full uint32s are also super handy for things like packing raw binary data formats
<TD-Linux> usually wrapping to 0 and wrapping to negative are equally disastrous tbh
<TD-Linux> emeb, nice! are you making actual sine waves or apple II tier sine waves
<emeb> TD-Linux: Actual sinewaves.
<emeb> I've got an NCO running to generate the colorburst freq. That runs through a little sine LUT.
<emeb> Only 4 bits signed. Then I've got a 4-bit weighted R DAC to drive the 75ohm video.
<emeb> right now it's only 2 colors hard-coded in the HDL, but I'm going to add a color memory and a mapping LUT for fore/back color selection.
Bike_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
emeb has quit [Quit: Leaving.]
Bike_ is now known as Bike
tpw_rules has quit [Ping timeout: 268 seconds]