<sorear>
whitequark: how does scan_ir work? I thought (last time I read 1149.1) that directly probing IR length wasn't possible, because component designers could choose the binary value of IDCODE freely
<whitequark>
sorear: in theory yes
<whitequark>
it makes an educated guess and tries to see if it's wrong
<whitequark>
in practice everyone makes it 10+
<whitequark>
because 1149.1 is dumb about that
<sorear>
had no idea that was a common convention
<whitequark>
i mean
<whitequark>
i don't know if it is but all devices i've tried so far follow it
<sorear>
(is there a nice list of these conventions anywhere, for someone who might be designing a TAP for kicks soon?)
<whitequark>
and, it obviously makes sense if you think about it for more than a minute
<sorear>
yes, but there are four obvious ways to do it (10+ 0+1 01+ 1+0) and no obvious schelling point
<whitequark>
no
<whitequark>
you have to start with "10"
<whitequark>
it's in 1149.1
<whitequark>
IR must be at least two bit long and start with 10
<whitequark>
i have no idea why they don't require 10+, probably some legacy device
pie__ has quit [Remote host closed the connection]
<sorear>
have all of the devices you've tested had IDCODEs?
<whitequark>
yes
<whitequark>
but if it has BYPASS by default you can still count it
<whitequark>
since IDCODE starts with 1 and BYPASS is 0
<azonenberg_work>
whitequark: so there is a different strategy i use in jtaghal
<azonenberg_work>
If a device has IDCODE, the IDCODE must be loaded into IR during test-logic-reset
<azonenberg_work>
So the first thing I do to figure out how many devices are in the chain
<azonenberg_work>
is to reset the chain, then shift out as many 32-bit IDCODES as I can
<azonenberg_work>
each time check if i found a bypass instead
<azonenberg_work>
This lets me get the total device count in the chain, plus the IDCODE of everything that has an IDCODE
<whitequark>
azonenberg_work: yes
<whitequark>
that is what i do in glasgow
<azonenberg_work>
Then I flush the chain with a few thousand constant 1s to bypass everything
<azonenberg_work>
(in shift-ir)
<azonenberg_work>
then shift 0s until I see an 0, to get total IR length
<azonenberg_work>
at that point, figuring out where all the IRs go is basically a knapsack problem
<azonenberg_work>
So i patch in the known ones and hope i have only one unknown
<azonenberg_work>
I do not currently have any heuristics for handling multiple unknown IR lengths
<whitequark>
right, i've seen that code
<whitequark>
i wonder if my IR length autodetection will work well
<rqou>
how do you handle socs with a jtag control block that will splice in/out the other blocks?
<whitequark>
there's currently no way to override it
<whitequark>
rqou: i redo the scan every time i select a tap
<whitequark>
the entire thing
<azonenberg_work>
rqou: Yeah, i do the same thing
<azonenberg_work>
I re-scan any time i change the tap config
<azonenberg_work>
Which is rare, thankfully
<azonenberg_work>
in all of my testing so far i have only found one (i.mx i think?)
<azonenberg_work>
And i just configure it once then re-scan and call it good
<azonenberg_work>
(there is an option to switch in every tap)
<sorear>
what is the "tap config" in this context?
<azonenberg_work>
sorear: many complex socs have multiple taps that aren't always in the chain
<azonenberg_work>
For example, Zynq has a strap pin (there's no runtime/software setting)
<azonenberg_work>
to have the ARM and FPGA TAPs be in the same scan chain
<azonenberg_work>
This is default, but you can override with the strap and have the main scan chain only have the FPGA TAP
<azonenberg_work>
Then the ARM TAP is brought out to pins inside the FPGA fabric, so you can configure the FPGA and bring the ARM JTAG out to FPGA GPIOs
<azonenberg_work>
and use two different jtag tools on them
<azonenberg_work>
rqou: shiny
* azonenberg_work
is looking forward to being able to do his next-gen network rollout
<sorear>
so there's no standard action that is likely to result in taps appearing or disappearing?
<azonenberg_work>
sorear: correct
<azonenberg_work>
It's entirely chip specific registers or strap pins
<rqou>
but plenty of nonstandard options
<azonenberg_work>
The only way to know how to do it is to have a datasheet for that part
<azonenberg_work>
And, once you've done it, then you have to re-scan the chain because none of your saved chain state is valid anymore
<sorear>
unrelated: how mad do people get if you make a tap that runs on the system clock and won't shift if the system clock is halted
<azonenberg_work>
sorear: probably very
<azonenberg_work>
that sounds like a horrible idea
<azonenberg_work>
You should run your tap in the TCK domain then have clock domain crossing from there to your internal domains
<rqou>
that doesn't sound too atypical though
<azonenberg_work>
rqou: eh, its ok to have operations not execute or something
<rqou>
would not be the worst sleep-state-related debugger issue i've seen or heard of
<azonenberg_work>
but having it not shift at all could be fatal if you had (say) a jtag-programmable clock synthesizer
<azonenberg_work>
Those do exist and i've seen them
<azonenberg_work>
So if your PLL isnt enabling your chip's clock by default
<azonenberg_work>
and you can't shift through it to make the PLL turn on that output
<azonenberg_work>
your board is a brick
<azonenberg_work>
The jtag chain is like the lowest level functionality that needs to work, period, as long as you have power
<rqou>
also the source of constant "and then when debugging this hax applies to sleep states"
<rqou>
which makes it then impossible to actually debug sleep states :P
<rqou>
tl;dr please don't do that, but if you do you won't be any worse than existing Vendors(TM)
<azonenberg_work>
rqou: when i was working on TACOSHIELD
<azonenberg_work>
I had VCCAUX for a coolrunner powered by a rail that shut down in sleep
<azonenberg_work>
And to test sleep behavior, of course the first thing i did was hard-wire the coolrunner (my PMIC) to put the board in sleep and never wake up...
<TD-Linux>
my favorite was a coldfire v1 where they hacked on usb afterwards
<TD-Linux>
so the usb would only work when the core ran at 48mhz
<TD-Linux>
and also if you executed the 68k wait for interrupt instruction, usb would break
<rqou>
lol
<rqou>
i believe it
rohitksingh has joined ##openfpga
77FAAKZDQ is now known as Kitlith_
<sorear>
ok but which crystals do you need to replace to overclock a usb
rohitksingh1 has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh1 has quit [Client Quit]
pie_ has joined ##openfpga
pie_ has quit [Excess Flood]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 244 seconds]
rofl_ has joined ##openfpga
jcarpenter2 has quit [Read error: Connection reset by peer]
rofl_ has quit [Read error: Connection reset by peer]
jevinskie has quit [Ping timeout: 250 seconds]
tpw_rules has quit [Ping timeout: 246 seconds]
tpw_rules has joined ##openfpga
<cyrozap>
sorear, azonenberg_work: Speaking of non-standard TAP configurations, a lot of modern phone SoCs have a single JTAG TAP/SWD DAP and use the ARM JTAG-AP to talk to multiple independent scan-chains inside the chip. That way, you can access all the JTAG TAPs inside the device (which would be things like coprocessor cores, modems, etc.) through a single physical port, without having to shift through a
<cyrozap>
giant scan chain and being restricted to the speed of the slowest TAP. Of course the downside is, you effectively end up tunneling JTAG over JTAG/SWD, so that's really fun to deal with in client software :P
<cyrozap>
Oh, and the other benefit is that it lets you access the other JTAG devices in the chip using only SWD, so you only need a single connection with SWDIO and SWCLK pins to talk to everything.
<cyrozap>
Whereas with a normal JTAG chain, you can't use SWD at all.
<cyrozap>
But yeah, OpenOCD can't take advantage of that natively right now (you can kind of get it working using the TCL-RPC interface, clever scripting, and multiple OpenOCD sessions) because it makes too many assumptions about how JTAG hardware works.
<azonenberg_work>
yeah, jtaghal lets you pass around adapter objects and do whatever you want on them
<azonenberg_work>
So you can do crazy things like having a JtagInterface backed by an ARMJtagDebugPort
<azonenberg_work>
I havent implemented JTAG-DP stuff yet
<azonenberg_work>
but it would fit cleanly into the object model
<azonenberg_work>
most of the big assumptions were that JTAG was the underlying transport for everything, and as i add SWD support that is being fixed
<azonenberg_work>
(although obviously devices like FPGAs that dont have SWD support can still safely assume jtag is the transport)
Dolu has joined ##openfpga
xdeller_ has joined ##openfpga
lexano has quit [Ping timeout: 250 seconds]
gruetzko- has joined ##openfpga
xdeller has quit [Read error: Connection reset by peer]
gruetzkopf has quit [Ping timeout: 268 seconds]
Dolu has quit [Read error: Connection reset by peer]
Dolu has joined ##openfpga
<tnt>
Oh ... almost made a mistake ... lp384 doesn't have internal oscillator :/ I guess I need one more component.
<travis-ci>
whitequark/Glasgow#73 (master - e4e718f : whitequark): The build passed.
<sorear>
pie_: if you have a glibc system handy, try opening the unversioned libc.so in a text editor
<pie_>
sorear, unversioned?
<galv[m]>
sorear probably means the shared object libc.so without a suffix (typically libc.so.6). However, all I have on my debian machine is this: /lib/x86_64-linux-gnu/libc.so.6
genii has quit [Read error: Connection reset by peer]
<galv[m]>
It just means that any code linking to /usr/lib/x86_64-linux-gnu/libc.so will actually link to /lib/x86_64-linux-gnu/libc.so.6 at runtime. I think it makes sense when you consider that libc.so.6 is normally at fixed location on linux machines.
<pie_>
ok but i dont really see the connection to what i pasted
<galv[m]>
Rather than the object file having a linker script embedded within it (described in your picture), in this case a linker script is masquerading as a linker file for whatever reason.
<sorear>
libncurses.so does the same thing sometimes
pie_ has quit [Ping timeout: 268 seconds]
jevinskie has joined ##openfpga
Maylay has quit [Ping timeout: 252 seconds]
Xark has quit [Changing host]
Xark has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
q3k has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
jcarpenter2 has joined ##openfpga
gruetze_ is now known as gruetzkopf
emeb has quit [Quit: Leaving.]
GenTooMan has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
Dolu2 has joined ##openfpga
Dolu has quit [Ping timeout: 244 seconds]
lexano has joined ##openfpga
ZombieChicken has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
<ZombieChicken>
Is there a way to simulate an FPGA in software?
<ZombieChicken>
I seem to recall there is a way, but I forget how
<qu1j0t3>
yes
<zkms>
verilator :3
<ZombieChicken>
icarus verilog?
<ZombieChicken>
or something similar?
<qu1j0t3>
that's one way
<qu1j0t3>
or vendor toolchains
<qu1j0t3>
or what zkms said
<ZombieChicken>
ok
<ZombieChicken>
hmm
<ZombieChicken>
Nothing that simulates the hardware itself without having to generate verilog (or I'm assuming VHDL)
<azonenberg_work>
ZombieChicken: how would you run code on it without writing HDL of some sort?
<Bike>
you could simulate an unprogrammed fpga that just sits there drawing power
<ZombieChicken>
azonenberg_work: Well, since some of the systems are 'open', I've been pondering trying to use Lisp or (more likely) Prolog (or some other logic language) to generate the code for the FPGA instead of having to go through some HDL
<azonenberg_work>
ZombieChicken: You still have to turn that into a gate-level netlist at some point
<azonenberg_work>
I guess if you wanted, you could have your tool spit out Yosys JSON or EDIF or something that was ready to go right to place-and-route and skip synthesis
<azonenberg_work>
(Or should i say, synthesize yourself)
<ZombieChicken>
the latter is what I was thinking
<azonenberg_work>
But it's trivial to back-convert from those formats to a Verilog netlist of individual FPGA cells
<azonenberg_work>
Which you can then feed to an HDL simulator
<azonenberg_work>
alternatively, you could make a cycle-accurate simulator of the actual FPGA hardware and give it a placed-and-routed bitstream
<azonenberg_work>
but this is overkill for most purposes and will run way slower than an RTL simulation
<ZombieChicken>
RTL?
<azonenberg_work>
Register transfer level
<azonenberg_work>
as in, a behavioral HDL model rather than one that models all of the subtleties of LUTS and interconnect
jcarpenter2 has quit [Read error: Connection reset by peer]
jcarpenter2 has joined ##openfpga
Dolu2 has quit [Ping timeout: 244 seconds]
Laksen has quit [Quit: Leaving]
<whitequark>
ZombieChicken: you need a HDL anyway
<whitequark>
it might be a lisp-based hdl, like migen is a python-based one
<whitequark>
but HLS is... kind of a dead end
<ZombieChicken>
HLS?
<whitequark>
high level synthesis
<whitequark>
like compiling c to gateware
<ZombieChicken>
ah
<ZombieChicken>
k
<whitequark>
it's a "sufficiently smart compiler" problem that cant really be solved
<azonenberg_work>
whitequark: kinda like compiling C to itanium? :p
<whitequark>
no that actually works
<whitequark>
llvm has an ia64 backend for some godforsaken reason
<whitequark>
and it's apparently okay?
<whitequark>
there's this whole chunk of llvm that basically exists to support itanium
<whitequark>
because i think for the gpu backends llvm serves as a "pre-codegen"
<whitequark>
and the vliw shit is in the vendor blobs
<sorear>
you are presumably aware that the vendor blobs are, themselves, llvm forks
<sorear>
i wouldn't be surprised if the vliw shit in llvm upstream has multiple out of tree users
<Bike>
compiling a programming language to hardware seems kind of nonsensical
<sorear>
i'm interested in understanding more about what HLS can actually do and why so many people seem to care so much about it
noobineer has quit [Ping timeout: 245 seconds]
<felix_>
for design space exploration hls might be useful; the "just take your c code and bring it to an fpga" is mostly marketing bullshit though