esden[m] has quit [Quit: Idle timeout reached: 172800s]
pg12 has quit [Ping timeout: 255 seconds]
pg12 has joined #glasgow
pg12 has quit [Ping timeout: 255 seconds]
pg12 has joined #glasgow
esden[cis] has quit [Quit: Idle timeout reached: 172800s]
jstein has quit [Quit: quit]
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #glasgow
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
nyanotech has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
ar-jan has joined #glasgow
ar-jan has quit [Ping timeout: 255 seconds]
marcus_c has quit [Ping timeout: 260 seconds]
jan2642[m] has joined #glasgow
<jan2642[m]>
:q
feldim2425_ has joined #glasgow
feldim2425 has quit [Ping timeout: 258 seconds]
vegard_e[m] has quit [Quit: Idle timeout reached: 172800s]
duskwuff[m] has quit [Quit: Idle timeout reached: 172800s]
nemanjan00[m] has joined #glasgow
<nemanjan00[m]>
I am implementing wiegand applet right now and I was thinking how cool it would be if there was integration with sigrok, to use real capture with simulation
<whitequark[cis]>
I think pyvcd has a vcd reader now, if that's the specific thing you want. that said, there is a record/replay feature that's used in e.g. SPI flash tests
<whitequark[cis]>
that also lets you use real captures (with Glasgow itself) with simulation, on a higher level
<nemanjan00[m]>
I will be looking into those options. I did write some code and wanted to start testing it, but, do not have hardware yet
<nemanjan00[m]>
Another question. I am beginner in HDL, so I just wanted to confirm I am on the right path...
<nemanjan00[m]>
I need to detect end of wiegand transmission (time passed without any transmissions)
<nemanjan00[m]>
I am guessing I just need to use counter for that and calculate number of clock ticks in time-frame I want to use as timeout? (just making sure there is not smarter solution)
<nemanjan00[m]>
* as timeout and just reset counter when I get data? (just
<adamgreig[m]>
The data/strobe was surprisingly annoying to do well at high bit rates on an fpga iirc, because it's not easy to generate a glitchless sample clock from the xor
<adamgreig[m]>
Presumably there's somehow a way.
<gruetzkopf>
iirc GRLIB recommends the "sample first, xor later" mode for FPGA, but that's been a while..
bvernoux has joined #glasgow
<adamgreig[m]>
Yea, I think that's the best way, but it limits what but rates you can keep up with as you need sufficient oversampling
<adamgreig[m]>
bit rates*
<gruetzkopf>
yeah. 60MBps SpW sounds *doable* from the fabric but that's definitly on the high side of feasible
<gruetzkopf>
at least on the LVDS header IO buffer bandwidth is not something one needs to think about - but going through the IO buffer and using external LVDS phys is safer
<adamgreig[m]>
If you had an external lvds phy you could perhaps also do an external xor and feed the fpga just clock and data?
<adamgreig[m]>
Basically an external 1355 phy at that point though...
<korrel[m]>
Yes, it's SpaceWire, LVDS voltage swing 350mV, common mode 1.125V-1.45V.
<korrel[m]>
Hm, yeah, I will look into an external driver.
<gruetzkopf>
lattice _claims_ the LVDS inputs will go to 400MHz, and i think i can see a feasible data path.
<gruetzkopf>
TX is much simper
<adamgreig[m]>
I think the lvds interface is fine in terms of signal level and clock
<adamgreig[m]>
It's just processing it in the fpga
<adamgreig[m]>
Or rather I'm sure it's fine in terms of those things as I've basically done it on an ice40hx before
<adamgreig[m]>
But external driver protects the glasgow fpga io in case you accidentally connect something a bit esd-y or overvoltage or so
<korrel[m]>
I think we still have some ICE40hx boards somewhere, did you use an open design for your implementation?
<adamgreig[m]>
(Glasgow is ice40hx is why I mention it)
<adamgreig[m]>
It wasn't open but also it's not 1355, just similar lvds voltages and bitrates
<korrel[m]>
Ok!
<korrel[m]>
In any case, I wouldn't immediately know how to get the data out of the ICE40hx onto a host without re-threadding the Glasgow design process....
* gruetzkopf
opens ECSS-E-ST-50-12C
<korrel[m]>
Yeah...
<gruetzkopf>
spacewire is a interesting-to-me spec but i have precisely zero devices with it. how low-level do you want to look at it?
<gruetzkopf>
just N-Chars or everything?
<gruetzkopf>
fully capturing both directions of a 60MBps link and pushing it to the sounds feasible. even if one is not trying to be clever about it that's "only" 240Mbit/s (16bit per transfered char, longest char on bus is timecode at 14 bits)
<gruetzkopf>
*to the host
<adamgreig[m]>
<korrel[m]> "In any case, I wouldn't immediat..." <- Yea, no point doing that, I think either Glasgow as-is or maybe with an external lvds xcvr just for added protection, only question is whether the ice40 can quite manage 60Mbps or not
<adamgreig[m]>
in terms of sampling the bus, not what happens once you get the data, that's probably ok
<gruetzkopf>
i think the most fiddly part here is actually sampling the data after xor, and detecting end of character, everything behind that is well handled by glasgow and amaranth (fifo, CDC, usb)
cakes has quit [Ping timeout: 258 seconds]
cakes has joined #glasgow
cakes has joined #glasgow
<korrel[m]>
Thanks for your comments, I will look into the FPGA "front-end" design, I will have to do that at some point anyway. 🙂
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
ar-jan has joined #glasgow
icb[m] has quit [Quit: Idle timeout reached: 172800s]
anubis has joined #glasgow
anubis has quit [Remote host closed the connection]
<Wanda[cis]>
I'm thinking about beefing up this applet
<_whitenotifier>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-478-dd08867c0783ea9c61efe474b03cb7c34966cffe - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
oooh!
<whitequark[cis]>
yees? :3
<Wanda[cis]>
the kind of beefing up that will involve renaming it to "program-xc9500"
<Wanda[cis]>
too bad the XC9500 fuse layout is kinda messy
<Wanda[cis]>
adding XC9500XV support would be much easier, except for the part where I have to make a breakout board
<Wanda[cis]>
also I can add support for setting the read/write lock bits, if anyone cares for that
<Wanda[cis]>
(the only functional difference between XC9500XL and XC9500XV is that XV has a "DONE" bit which you are supposed to program at the very end; it's in the middle of the bitstream array; XC9500 otoh has very different and more complex bitstream layout)