<Wanda[cis]>
for many devices, Vivado has _CIV/_SE/_LR variants, which appear to have an identical grid to the base device
<Wanda[cis]>
at least the _CIV devices have a different IDCODE, though
<Wanda[cis]>
wtf is this about
<Wanda[cis]>
the CIV devices appear to have software-limitted transceiver performance, and I found some vague information about this being about some chinese export control bullshit
<Wanda[cis]>
for SE I found an even more vague information about being "select edition"
<Wanda[cis]>
and LR is... no information
<Wanda[cis]>
(it appears to be new in this version, and only present for zu1eg, while _SE applies to a bunch of u+ and versal devices)
<Wanda[cis]>
I continue to be amazed by the trashfire that is versal
<Wanda[cis]>
they have like 3 different generations of AI engines, 2 generations of NOC tiles, 4 or so generations of DDR memory controllers, 3 generations of the ARM complex
<Wanda[cis]>
and it seems that whenever they create a new device, they just roll a random version of each; you'd expect them to use the newest rev of the AI engines on a new part with NOC2, but for some reason they stuffed the gen1 AI there
<Wanda[cis]>
oh, and also like 4 kinds of transceivers
<Wanda[cis]>
at least 5 different PCIE cores
<Wanda[cis]>
maybe their AI engines told them to do it
<mupuf>
Wanda[cis]: maybe this is a way to upsell current customers who have ready-made designs onto newer chips?
<mupuf>
Or they are really committed to A0 customer readiness
<mupuf>
Not sure what's the margins for FPGA vendors...
<mupuf>
Can't be so good given the current refresh cycles, but can't be so bad either given how big to he companies are and how dirt-cheap the nodes they are using are for volume parts are
melnary has quit [Read error: Connection reset by peer]
melnary has joined #prjcombine
q3k[cis] has quit [Quit: Idle timeout reached: 172800s]
h_ro has joined #prjcombine
<h_ro>
Wanda[cis]: for in-hardware testing, have you considered leveraging BSCAN primitives for scanning in/out of other primitives (example: debugging LUTRAM INIT patterns: https://github.com/openXC7/primitive-tests/tree/main/clb-tests/jtag-test). By offloading functional verification on host-side, you can reduce hardware utilization (making it easier to test small designs more quickly). Additionally, you do not need to declare IO pin/clock placement since
<h_ro>
everything is running of JTAG pins.
<h_ro>
running on*
<Wanda[cis]>
I have; in fact, this is exactly the plan
<Wanda[cis]>
it's also how I did it last time (XC9500 and XPLA3)
<h_ro>
Oh nice
<Wanda[cis]>
just INTEST that thing and all you need is 6 wires for JTAG
<h_ro>
right
<Wanda[cis]>
(well. not quite. I also learned the hard way that XPLA3 dedicated clock inputs bypass JTAG. but it still saved me a bunch of work.)
<Wanda[cis]>
in the end, it's very useful, but there's some things you just need to grab a scope for
<Wanda[cis]>
poking at the electrical-level config of IO pads is one example, PLLs are another
<h_ro>
Do you plan to use openocd or do you have something else in mind? I am currently working on a platform cable driver for openocd so that boards without external JTAG pins like ML605 can be accessed.
<Wanda[cis]>
no thanks, I prefer other means of self-harm
<Wanda[cis]>
so far I've been using glasgow scripts
<Wanda[cis]>
but yeah, that won't work for ... well a bunch of devboards that have an embedded platform cable or ftdi or whatnot
<Wanda[cis]>
last time I needed to deal with one of those (some funny digilent AVR-based JTAG-on-a-stick with custom protocol on basys2), I ended up just writing a driver + JTAG stack in Python
<Wanda[cis]>
though a more proper solution could be in order; after all, this project will need a production-grade programming tool at some point
<Wanda[cis]>
could just sit down and make an open-source impact
<whitequark[cis]>
Wanda[cis]: don't these usually have exposed pins or smth
<Wanda[cis]>
not always
<Wanda[cis]>
I tried SP605 and apparently they just. don't expose the JTAG anywhere