<whitequark[cis]1>
it's a cute hack but not something that we'll use
<whitequark[cis]1>
* we'll use for future revisions
<whitequark[cis]1>
it will probably be Gigabit Ethernet with USB2 fallback, based on cost and reliability concerns
redstarcomrade has quit [Read error: Connection reset by peer]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #glasgow
FFY00_ has joined #glasgow
FFY00 has quit [Ping timeout: 255 seconds]
FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #glasgow
pelrun[m] has quit [Quit: Idle timeout reached: 172800s]
meklort has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
jof__[m] has quit [Quit: Idle timeout reached: 172800s]
<sigstoat[m]>
i wanted to get w_level off of the in_fifo, and then discovered it wasn't a... real? FIFOInterface. this being python i spotted in_fifo._fifo. am i little bit cursed, or a lot cursed if i grab w_level off of that?
<sigstoat[m]>
i don't think this is the sort of thing anyone else will ever use, i'd just like to not spontaneously combust
redstarcomrade has quit [Read error: Connection reset by peer]
GNUmoon2 has quit [Remote host closed the connection]
<sigstoat[m]>
(extreme handwaving:) plugged my glasgow into the bus of a commander x16 (6502 retro pc thing), had an applet behave like a bargain basement 16550, routed the data to a pty, and bam.
m42uko_ has joined #glasgow
m42uko has quit [Ping timeout: 272 seconds]
<marcus_c>
If you want to use the Glasgow to emulate some USB device, one way to do it (at least on Linux) would be to write a shim that speaks USB/IP (https://www.kernel.org/doc/html/latest/usb/usbip_protocol.html) on one end, and communicated with the Glasgow using the usual frameworks on the other. I guess this would mostly be useful in cases where it's not feasible to just rewrite the top level application to use the Glasgow directly. :-)
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
notgull has joined #glasgow
notgull has quit [Ping timeout: 264 seconds]
GNUmoon2 has quit [Read error: Connection reset by peer]
GNUmoon2 has joined #glasgow
agg has quit [Ping timeout: 256 seconds]
agg has joined #glasgow
asdvek[m] has joined #glasgow
<asdvek[m]>
I'm learning to use glasgow and it looks like the previously built bitstreams are somehow cached between runs:
<asdvek[m]>
`I: g.device.hardware: device already has bitstream ID ...`
<asdvek[m]>
Is there a way to clear these cached bitstreams to force rebuild?
<miek__[m]>
--reload (advanced) reload bitstream even if an identical one is already loaded
<asdvek[m]>
Thanks, but that's not quite what I'm looking for. In this case I want to reduce the frequency in `jtag-opencd` applet so I really want to rebuild the bitstream instead of just loading in the old one again.
meklort has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<Attie[m]>
there is a cache, but it's pretty robust, and changes like this should trigger a rebuild
meklort has joined #glasgow
<Attie[m]>
if it's really not, please raise an issue (and outline your command line, etc...)
<Attie[m]>
you can also delete the `~/.cache/GlasgowEmbedded` directory as an immediate thing - would be interesting if this actually resolves the issue for you
<asdvek[m]>
After deleting the cache directory still gives the same message.
<Attie[m]>
what's the message? can you expand on the problem?
<asdvek[m]>
Ok looks like the problem went away after all. I cannot reproduce it anymore :D
<Attie[m]>
if it reoccurs, and deleting the directory is the only way to clear it... please log an issue! 😊
<Attie[m]>
give as much info as you can - command line, changed sources, etc...
<asdvek[m]>
I suppose in this case there's no need actually rebuild it since I was decreasing the clock frequency
<asdvek[m]>
* no need to actually rebuild
<Attie[m]>
some items are run-time configuration, and aren't built into the bitstream, so don't trigger a rebuilt... very possible that's what you were seeing
Foxyloxy_ has joined #glasgow
Foxyloxy has quit [Read error: Connection reset by peer]
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]1>
first, there is the cache directory Attie told you about; second, there is the device itself
<whitequark[cis]1>
where it remembers the bitstream that was loaded and if the loaded one and the new one are the same, the bitstream is not reloaded
<whitequark[cis]1>
to clear the former (extremely unlikely to do anything), just delete the directory
<whitequark[cis]1>
to clear the latter, press e-stop to power cycle the device
<whitequark[cis]1>
unless you do something weird in an applet involving custom clock domains and/or reset-less registers, the latter is also unlikely to do anything
<whitequark[cis]1>
as for the clocking, iirc jtag-openocd does not have a clock per se, because of how it works
<whitequark[cis]1>
it has a minimum period between pin changes
<whitequark[cis]1>
changing that automatically rebuilds the applet; the rebuild is triggered based on the generated RTLIL and is not dependent on any tracking of parameters. it's a hash of the netlist
<whitequark[cis]1>
(to be more precise, it is a hash of the netlist and all of the tools that would be used to build this netlist if you actually built it; and all of the tools are confined to a wasm container which makes them fully deterministic and platform independent)
<Attie[m]>
thanks for pointing out the device (🤦♀️) and extra info
<Attie[m]>
this may be a dumb question... my brain isn't fully "on" today
<Attie[m]>
I'd like to produce an output pattern on a pin... I've got a Const(0b0100110011, unsigned(10)) which I then produce a counter for ctr = Signal(range(len(pattern)))
<Attie[m]>
I'd then like to put one of the bits from that pattern onto a pin, but m.d.comb += pin.eq(pattern[ctr])) doesn't work
<whitequark[cis]1>
bit_select
<Attie[m]>
magic, thanks
<whitequark[cis]1>
but you want to register it
<whitequark[cis]1>
if you assign it in comb domain it will glitch
<Attie[m]>
righto, I wondered
<whitequark[cis]1>
usually what i do is actually a circular shift register
<whitequark[cis]1>
like in the old times
<whitequark[cis]1>
that has zero logic and can't glitch
<Attie[m]>
heh, I thought about doing that, but figured this might be better
<whitequark[cis]1>
no the shift register is preferred
<Attie[m]>
a basic frequency output, and a digital pattern generator
<whitequark[cis]1>
these seem like they should be one applet
jan2642[m] has quit [Quit: Idle timeout reached: 172800s]
<Attie[m]>
quite possibly!
vegard_e[m] has quit [Quit: Idle timeout reached: 172800s]
<asdvek[m]>
Makes sense. Thanks for your input!
<whitequark[cis]1>
<Attie[m]> "scope_20240607_141655.png" <- on second thought, for a pattern generator, i would want the 1st (leftmost) bit to appear on the wire first
<whitequark[cis]1>
this is, unless i egregiously misremember, the way you usually see it in a SerDes
<whitequark[cis]1>
* it in documentation for a SerDes
<whitequark[cis]1>
i'm also somewhat concerned about the use of a PLL... for something upstream i'd want the main clock to be used if possible, and a PLL if not
<Attie[m]>
ok - i'm not necessarily looking to get these upstreamed (as discussed previously)... more of a toolkit for this project i'm working on
<whitequark[cis]1>
ah i see
<whitequark[cis]1>
(i don't recall the previous discussion)
<Attie[m]>
i need to be able to produce signals varying frequencies, so figured the PLL was best / easiest
<Attie[m]>
oh, sorry... i should have clarified earlier. it was around "applets to scratch individual itches"
<whitequark[cis]1>
so the ideal, most flexible configuration is a frac-N synthesizer with its base frequency produced by a PLL
<whitequark[cis]1>
there you can trade off hardware capabilities, phase error, and frequency error
<Attie[m]>
interesting - i'll need to learn more about that some time
<Attie[m]>
sadly, for now (and for far too long), i've been in "why won't this project start working" mode, and it hurts
<whitequark[cis]1>
basically, it goes like: system clock -> [PLL, no PLL] -> wide fixed point counter that increments by a fractional value each cycle (eg 16.16 incrementing by 16.16) -> each time the counter overflows the next bit is chosen
<whitequark[cis]1>
this is afaik (i am not a domain expert) more or less the architecture that proper arbitrary waveform generators use
<Attie[m]>
ah, i think I've seen them in some baudrate generators
<whitequark[cis]1>
yes
<Attie[m]>
nice
<whitequark[cis]1>
if your frequency is a whole value, you have no phase error (0% additional jitter on top of your reference clock jitter)
<whitequark[cis]1>
s/frequency/increment/
<whitequark[cis]1>
if your increment is a fractional value you get less frequency error (more accurate average frequency of transitions) but more phase error (some transitions are early and some are late)
<whitequark[cis]1>
the PLL can be used to reduce phase error at the cost of, well, using one PLL for this, because you can multiply your reference clock by a rational value so that your frac-N divider no longer
<whitequark[cis]1>
* no longer adds any jitter
<whitequark[cis]1>
this is not trivial to build because there's several values you can optimize for, and while this is mostly a linear programming problem, you have inequalities
<whitequark[cis]1>
like... the PLL VCO frequency is limited for example, and the PFD has its own limitations on how low it can go
hardkrash[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #glasgow
<Attie[m]>
sounds good, thanks for the info
<Attie[m]>
is your preference for "not PPL" because it's a limited resource? or something else
<Attie[m]>
*PLL
<whitequark[cis]1>
it is a limited resource and adds complexity. for example when we migrate to ECP5 in revD, all applets that use PLL will need to be revisited
<Attie[m]>
gotcha
<whitequark[cis]1>
also, while this doesn't matter for a fixed waveform generator, if you wanted the waveform to be runtime configurable, you'd need CDC
<whitequark[cis]1>
and the PLL needs time to lock... I think the module you're using does assert domain reset, but I'm not even sure it releases it correctly?