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