whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
redstarcomrade has quit [Read error: Connection reset by peer]
josHua[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
Eli2_ has joined #glasgow
Eli2 has quit [Ping timeout: 264 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
get0rix[m] has joined #glasgow
<get0rix[m]> Hi! Silly question maybe, but what is the shortest pulse Glasgow can produce on IO? Looks like self.pin.o.eq(~self.pin.o) generates 24MHz strobe with pulse around 21ns and this is the limit. Just pushing boundaries for my glitch setup 😄
<whitequark[cis]> get0rix: this is the shortest you can reliably go without using a PLL
<whitequark[cis]> in theory you should be able to go as low as 10 ns, possibly down to single nanoseconds
<whitequark[cis]> I have a cursed idea I could test
redstarcomrade has joined #glasgow
<get0rix[m]> Hi! Silly question maybe, what is the shortest pulse Glasgow can produce on port IO? Looks like self.out.o.eq(~self.out.o) generates 24MHz strobe wth pulse width around 21nm, while I would expect it to be 48MHz as it is set by sys_clk_freq=48e6 with pulse width around 10nm. Clearly I am missing something. Thanks for any hints!
<get0rix[m]> * Hi! Silly question maybe, what is the shortest pulse Glasgow can produce on port IO? Looks like self.out.o.eq(~self.out.o) generates 24MHz strobe wth pulse width around 21nm, while I would expect it to be 48MHz as it is set by sys_clk_freq=48e6 with pulse width around 10nm. Clearly I am missing something. Pushing my glitch setup to the limit. Thanks for any hints!
<whitequark[m]> I replied to you on Matrix, unfortunately the bridge is having issues at the moment
<get0rix[m]> Matrix? sorry, looks like I am behind everywhere 😄
<whitequark[m]> we have a Matrix channel as well as the Discord one
<joshua_> I am now curious as to how cursed we are talking here
<get0rix[m]> Thanks Catherine! I will start looking for Morpheus to get the pill for Matrix 😄
josHua[m] has joined #glasgow
<josHua[m]> the bridge does seem to be working between IRC and Matrix
<josHua[m]> (libera #glasgow)
<fishmonger[m]> You can cheat a bit, Go to https://glasgow-embedded.org/ -> Community -> irc logs. The IRC bridge is working.
<josHua[m]> Discord -> {matrix,IRC} seems to be working as well, just {matrix,IRC} -> Discord is wedged at the moment
<get0rix[m]> What do you think, I am lazy??? I will install Matrix client and login there 😄 😄 😄
<josHua[m]> well, I am lazy, and use IRC because I cannot figure out Matrix 🙂
getorix[m] has joined #glasgow
<getorix[m]> yep, no biggie, pretty straight forward :D
<whitequark[m]> this is the best I can manage to do
<whitequark[m]> but it uses some really cursed circuitry
<getorix[m]> wow
<getorix[m]> this is with hardware mod I assume?
<whitequark[m]> no
<whitequark[cis]> this is completely unmodified glasgow
<getorix[m]> wow ^ 2
<whitequark[cis]> my entire test setup
<whitequark[cis]> is this impressive?
<getorix[m]> Thanks heaps, Catherine! I will put it into my aplets and give it a shot 👍️
<getorix[m]> s/aplets/applet/
<whitequark[cis]> note that sometimes the FPGA placer makes decisions that make this circuit just Not Work (there is no pulse on the output)
<whitequark[cis]> this is unavoidable and why I don't recommend it in general
<whitequark[cis]> it is possible in principle to make it reliable but my nextpnr-fu is not enough
<getorix[m]> Everything you do is impressive :)
<whitequark[cis]> I mean I don't do hardware glitching
<whitequark[cis]> I don't know how good 3ns is
<getorix[m]> pretty damn good, I managed to get same similar only with Teensy 4.0
<getorix[m]> * pretty damn good, I managed to get similar result only with Teensy 4.0
<getorix[m]> * pretty damn good, I managed to get similar result only with Teensy 4.0 (it is 600MHz MCU though)
<whitequark[cis]> apparently this beats ChipWhisperer
<getorix[m]> exactly
<whitequark[cis]> huh.
<whitequark[cis]> I accidentally
<joshua_> that is getting fast enough that your probing technique there and scope start to be a limiting factor
<whitequark[cis]> oh for sure
<joshua_> it sort of seems like you may have unintentionally made a TDR as much as anything else
<whitequark[cis]> so…. it's acutally better
notgull has joined #glasgow
<whitequark[cis]> let me show you a recapture i did with a better probing technique
<joshua_> yeah, I think so. what are you using as a scope?
<whitequark[cis]> rigol ds1104z
<joshua_> wow you are getting way more than your money's worth of bandwidth there
<getorix[m]> hm, I guess I need to figure out the magic behind these trigger_dx and SB_LUT4 buffers 🤔
<whitequark[cis]> i'm xoring a signal with itself, but one of the xor inputs have a delay
<whitequark[cis]> every time the signal changes value you get a pulse like this
<getorix[m]> 3ns? this is beyond my understanding now, how... on 48MHz
<whitequark[cis]> it doesn't depend on the clock frequency at all
<joshua_> it does depend on the ambient temperature, though
<whitequark[cis]> it's based on the intrinsic properties of the FPGA fabric
<getorix[m]> 🤯
notgull has quit [Ping timeout: 264 seconds]
<getorix[m]> the first source has comb set from ClockSignal, so I thought they are related, but looks like this second attempt is whole new way :)
<joshua_> https://www.eevblog.com/forum/projects/yet-another-fast-edge-pulse-generator/msg1269125/#msg1269125 indicates that you definitely have hit the limit of what you can see
GregNGM has quit [Quit: No Ping reply in 180 seconds.]
GregNGM_ has joined #glasgow
h1ghju1ce[m] has quit [Quit: Idle timeout reached: 172800s]
theorbtwo[m] has quit [Quit: Idle timeout reached: 172800s]
<_whitenotifier-9> [glasgow] whitequark commented on issue #552: Reloading FPGA bitstream causes all outputs whose Vio is enabled to strongly drive high - https://github.com/GlasgowEmbedded/glasgow/issues/552#issuecomment-2183973870
redstarcomrade has quit [Read error: Connection reset by peer]
<_whitenotifier-9> [glasgow] whitequark opened pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark commented on issue #552: Reloading FPGA bitstream causes all outputs whose Vio is enabled to strongly drive high - https://github.com/GlasgowEmbedded/glasgow/issues/552#issuecomment-2184004218
<_whitenotifier-9> [glasgow] whitequark commented on pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588#issuecomment-2184004693
<_whitenotifier-9> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-588-3940a01b80d3674e5ec02b1a5762247fcebf005f - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-9> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-588-3940a01b80d3674e5ec02b1a5762247fcebf005f - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark commented on pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588#issuecomment-2184011317
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
meklort_ has joined #glasgow
meklort has quit [Ping timeout: 268 seconds]
meklort_ is now known as meklort
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark synchronize pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-588-3940a01b80d3674e5ec02b1a5762247fcebf005f - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-9> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 2 commits to main [+0/-0/±4] https://github.com/GlasgowEmbedded/glasgow/compare/3940a01b80d3...464605b317a9
<_whitenotifier-9> [glasgow] whitequark closed pull request #588: Turn off Vio on revC before resetting FPGA as a safety measure - https://github.com/GlasgowEmbedded/glasgow/pull/588
<_whitenotifier-9> [glasgow] whitequark closed issue #552: Reloading FPGA bitstream causes all outputs whose Vio is enabled to strongly drive high - https://github.com/GlasgowEmbedded/glasgow/issues/552
<_whitenotifier-9> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-588-3940a01b80d3674e5ec02b1a5762247fcebf005f - https://github.com/GlasgowEmbedded/glasgow
stary2001[m] has quit [Quit: Idle timeout reached: 172800s]
<_whitenotifier-9> [glasgow] whitequark opened pull request #589: Update firmware to include fix for #588 - https://github.com/GlasgowEmbedded/glasgow/pull/589
<_whitenotifier-9> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-589-464605b317a93777c85ca11481dbed8940ca8d89 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-9> [glasgow] whitequark commented on pull request #191: applet.program.ecp5_sram: Initial ecp5 SRAM applet - https://github.com/GlasgowEmbedded/glasgow/pull/191#issuecomment-2184030132
<_whitenotifier-9> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/464605b317a9...ebf6eabeb7c1
<_whitenotifier-9> [GlasgowEmbedded/glasgow] whitequark ebf6eab - software: update firmware.
<_whitenotifier-9> [glasgow] whitequark closed pull request #589: Update firmware to include fix for #588 - https://github.com/GlasgowEmbedded/glasgow/pull/589
<whitequark[m]> PSA: I just fixed an important safety issue (https://github.com/GlasgowEmbedded/glasgow/issues/552) where reconfiguring the FPGA with a new bitstream with Vio voltage on would cause all pins to be momentarily driven to a strong high level; everyone should pull from the repository and run `glasgow flash`
<whitequark[m]> esden (@_discord_269693955338141697:catircservices.org) can you use the crowdsupply update mechanism to mention this?
alethkit[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[m]> yeah, our [install instructions](https://glasgow-embedded.org/latest/install.html) show the right commands
<whitequark[m]> and if you updated correctly you should see a message about "API level 3"
<getorix[m]> Catherine: I have been playing with your pulse snippet, spent time digging into amaranth docs etc. Correct me if I am wrong, but as I understand the pulse is a result of physical delay during signal propagation thought d1-d4 trigger LUTs? Like what is supposed to happen instantly in theory, still requires fraction of time in real world. Did I get it right?
<getorix[m]> * trigger LUTs exploited by xor logic? Like
<whitequark[cis]> basically yes
<getorix[m]> wow, thanks!
<whitequark[cis]> i mean the theory says the same as the practice here
<whitequark[cis]> a LUT4 is a real physical unit
<whitequark[cis]> it's just that synchronous logic uses a certain model of the world (zero delay model) that is valid under certain conditions (all timings met)
<whitequark[cis]> i am violating the timings, or rather their associated restrictions, by not registering the output of a comb circuit
<getorix[m]> I am new into FPGA programming, that is why I thought all signals change same time if they are connected (what I call theory) :)
<whitequark[cis]> this is well known to potentially cause glitches. here, i can control the glitch enough to make it desirable
<whitequark[cis]> I see
<whitequark[cis]> yeah, I am exploiting the areas where the simple model no longer works
<getorix[m]> it works pretty cool, and by changing the length of cascade it is possible to fine tune it further :)
<getorix[m]> s/cool/good/
<getorix[m]> * it works pretty good, and by changing the length of trigger cascade it is possible to fine tune it further :)
<whitequark[cis]> somewhat, yes
<whitequark[cis]> note that wires also add finite time
<whitequark[cis]> so making the cascade too large will make it slower than youd expect looking at LUTs alone
<getorix[m]> yep, but seems good enough to control EMFI pulse width
<whitequark[cis]> this should kick in at 7 stages or so
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
modchatbot[m] has joined #glasgow
<modchatbot[m]> 🥲 (Queue ID [1300..1400])
mmerkel has quit [Ping timeout: 256 seconds]
<joshua_> hm, you could presumably also get better pulse characteristics by using the LVDS outputs
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #glasgow
theorbtwo[m] has joined #glasgow
<theorbtwo[m]> The "lvds" pins are just raw fpga pins, so maybe, but also danger.
esden[m] has joined #glasgow
<esden[m]> whitequark (@_discord_182174208896401419:catircservices.org) I am adding the necessary text to the update right now.
<tomkeddie[m]> whitequark (@_discord_182174208896401419:catircservices.org) am looking to buy some of those Ethernet boards in my taobao order next month, wondering if you're still planning to add support? I guess long term we'll need our own add-on pcb.
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #glasgow
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #glasgow
cr1901 has quit [Read error: Connection reset by peer]
ewenmcneill[m] has quit [Quit: Idle timeout reached: 172800s]
EwenMcNeill[m]1 has quit [Quit: Idle timeout reached: 172800s]
cr1901 has joined #glasgow
ewenmcneill[m] has joined #glasgow
<ewenmcneill[m]> https://github.com/GlasgowEmbedded/glasgow/pull/562 is the (still marked WIP) Ethernet RGMII PHY. Glancing at the TODO list, it looks like "working, but want to refactor the code".