<_florent_>
dkozel: it's possible to use Chipscope on LiteX design, but you'll have to use the generated names in the verilog. On LiteX designs, it's generally easier to use LiteScope, but in some specific cases i'm also using Chipscope
<_florent_>
somlo: nice for the litescard driver, are both reads and writes working?
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
_franck_ has quit [Ping timeout: 272 seconds]
<acathla>
What's the best way to build my own C code against a litex design? It builds a bios in build/software folder but Makefiles are somewhere else in litex.
<lkcl>
the only major "pain" was (after taking ulx3s.py) to work out how to do "build", and i had to have a right-old dig into litex for a few hours and eventually worked it out
<lkcl>
override GenericPlatform and cut/paste the verilog build code from LatticePlatform, that did the trick
<lkcl>
ahh it is ok to add a 3rd bus (in this case a JTAG master) to periph_buses, right?
<_florent_>
otherwise, for self.periph_buses, all the buses of the list will be connected yes
<lkcl>
ahh goood
<_florent_>
(and adapted in width and standard if necessary)
<lkcl>
i was expecting that to work, i did however wonder if it would try to do something unexpected if there weren't 2 entries in the list
<lkcl>
okaay. excellent
<_florent_>
the SoC builder is logging these informations while building the SoC, so you can see which peripheral is added, if it's eventually adapted, etc...
<lkcl>
as i'm adding JTAG - *real* JTAG (thanks to staf Chips4Makers for creating a full TAP FSM)
<lkcl>
is there a way to connect those 4 pins to openocd in sim.py?
<_florent_>
not yet no, but that could indeed be useful
<lkcl>
i'd like to actually connect openocd to the simulation and e.g. single-step it, upload to memory and so on
<lkcl>
the most logical / simplest route would be a network port
<lkcl>
okaay. so "not quite actual jtag" but "more like how Xilinx BSCANE2 works"
<lkcl>
still, thank you - it's something i could use to run on the ECP5.
<lkcl>
haha of course i could just shove a USB JTAG adapter onto 4 spare pins.... :)
<daveshah>
I've done that in the past tbh
<somlo>
_florent_: writes work too; but there's something weird going on, like some sort of intensive internal polling -- the "computer" becomes really slow and unresponsive once the litex_mmc driver successfully finds and intializes the card
<somlo>
but I'm still happy -- fixing something that already kinda works is better than a brick doing *nothing* :)
<somlo>
also, back when I used spi-mode sdcard, the kernel was polling for the presence of the card, and could tell when it was inserted/ejected -- that's not (yet) working with litesdcard, and might have something to do with the slowness
<tpb>
Title: EUROPRACTICE | IC Service (at europractice-ic.com)
<somlo>
lkcl: cool, thanks
<somlo>
chip fabrication is a thing I know nothing about, but feel an obligation to learn about
<lkcl>
yeah, very! with NLnet sponsorship paying for the MPW we can "experiment" and learn without having to pay EUR 18,000
<somlo>
my uni has a 4-5 semester course sequence in the ECE dept (free to staff/employees who can convince the prof to let them enroll)
<lkcl>
somlo: yes. things are definitely stepping up a gear
<lkcl>
nice!
<somlo>
but then covid happened, and I don't feel like taking in-person classes for another while :)
<lkcl>
somlo: get plenty of morning sunlight, and when you can't, get some pharmaceutical-grade 50,000 AU Vitamin D
<lkcl>
and if you do get it for god's sake order and absolutely insist to the people that are looking after you to provide you with micro-aerosolised doses of the steroids used for treating asthma.
<lkcl>
getting there
<lkcl>
build/sim/core/sim.c Could not find interface jtag with index 0
<lkcl>
now i have to call... platform.extensions... something?
<lkcl>
i've seen this somewhere in spi_sdcard
<lkcl>
dang!
<lkcl>
that worked. had to remember to actually request the jtag platform and connect up the pins just like for the LS180 ASIC
<st-gourichon-fid>
Hi all, including _florent_ . We are concerned about building software without manually copying csr.h and the like. We are aware about linker.ld and cousins.
<st-gourichon-fid>
Generated files for a design include output_format.ld and regions.ld which is good. We are comparing the various existing linker.ld to figure out.
<esden>
acathla: sajattack[m] the code for the C example is generated by litex. These are the same headers as the ones used for the bios. I just copy them out from the litex build directory. I thought I described it in one of the README files... You will need to copy the headers out of litex every time you change anything regarding CSRs.
<esden>
rust example is much more clever, it uses the generated svd, and on the fly generates the necessary glue definitions for you.
st-gourichon-fid has quit [Ping timeout: 246 seconds]
st-gourichon-fid has joined #litex
<sajattack[m]>
yeah I'm more familiar with how the rust side works