#milkymist IRC log for Wednesday, 2012-11-21

azonenbergAnybody here work with the BSCAN primitive?09:09
mumptaithe nor flash programmer of urjtag does, iirc09:10
mumptai(got to run) bye09:10
azonenbergi'm trying to make an API that allows point-to-point contact through multiplexers from one (or more) PC-based applications to cores on the FPGA09:11
azonenbergso that i can have say a gdb bridge and a bus sniffer both running simultaneously using the single jtag interface09:11
azonenbergvia a packet-switched protocol using USER1 as an address, USER2 as the per-core IR, and USER3 as the per-core DR09:12
azonenbergso you basically have virtualized TAPs on each core09:12
lekernelazonenberg: http://www.milkymist.org/misc/ml401_flasher-1.0.tar.bz209:21
lekernelI wrote that a while ago09:22
lekernelit's for virtex4 though09:22
azonenberglekernel: i'll take a look09:23
azonenbergdoes the system i mentioned sound useful?09:23
azonenbergi want a TCP server that allows you to configure FPGAs with bitstreams, do boundary scan operations, and communicate with virtualized TAPs on fpgas through the USER* instructions09:24
azonenbergit's going to be nice and generic, i'm going to support the Digilent API, openocd, and possibly raw ftdi adapters as back ends09:24
lekernelcan you make it generic enough that GDB isn't an assumption anymore?09:35
lekerneli'd use something like that to measure memory bandwidth, dataflow token rates, etc.09:35
azonenbergThe goal is to expose an API that allows you to open a TCP socket to the server and then select "/scanchain0/device0/core2"09:36
azonenbergyou will then use a simple frame-based format consisting of {opcode, length, data} or similar09:36
azonenbergfor example "set IR to 16 bits 0xDEAD"09:36
azonenberg"set IR to 32 bits BAADC0DE and return result"09:36
azonenbergthe idea is to use jtag as a link-layer protocol and define a socket-style transport layer on top09:37
azonenbergand then you can run any application-layer traffic you want on top of those connections09:37
lekernelalso to control embedded logic analyzers09:37
azonenbergI intend to add a RED TIN module for it09:37
azonenbergIt will also allow you to speak directly to the chip rather than to cores on it09:38
azonenbergto query serial numbers, do boundary scan, and Xilinx-specific commands for loading bitstreams etc09:38
azonenbergthough you could of course add another class that derives from FPGA and JtagDevice other than XilinxSpartan6Device09:38
azonenbergIt will support plug-and-play to the extent possible09:39
azonenbergautomatically identifying FPGAs via IDCODE and then querying USER* instructions to see if one of my cores is present on it09:39
azonenbergand if so, finding out how many cores are present and getting ID codes off each09:39
azonenbergso you'll be able to autodiscover "JTAG plug-and-play controller at address 0",  "LM32 GDB interface at address 1", "RED TIN logic analyzer at address 2"09:40
azonenbergSo then you'd be able to start up RED tin and connect to the server and it'd give you a drop-down list of LA servers discovered09:40
azonenbergyou could thus have multiple LAs present09:40
azonenbergi dont think chipscope can do that :D09:40
azonenbergthe big problem with chipscope though is that it doesnt play well with softcore ICD since i think it monopolizes the USER* instructions09:41
azonenbergthis system would be built around multiplexing and sharing from the start09:41
azonenbergAnd by virtue of being socket based, remote config/debug comes almost for free09:41
lekerneland it's horrible java bloatware09:41
azonenbergRED TIn is still a bit buggy but is getting there, and is like 2000 lines of C++ and verilog :D09:42
azonenberg1k of each roughly09:42
azonenberglightweight, does exactly what it needs to and not a single thing more09:42
lekernelwith more bugs than a rainforest. maybe it improved since then, but I never touched it again since I tried it in 2008, couldn't get it to work, and kept myself at a safe distance09:42
azonenbergwhile meanwhile RED TIN is open source and, while not fully debugged, the first beta tester i gave it to caught a memory controller bug within like an hour or two of downloading it09:43
azonenbergi'm a big fan of minimalism in hardware/software design09:43
lekernelI'll want to improve in-system debugging support in migen at some point09:44
azonenbergwell feel free to use this system09:45
azonenbergI've only been working on it for a day or so (~1kloc) but will be pushing it to google code under a BSD license in a week or so once i have something actually usable09:45
azonenbergit's already able to connect to my Atlys via the embedded Digilent programmer, probe the chain, and identify the chip as an XC6SLX45 rev 309:45
lekernelhave a lib of cores ready that can capture bus transactions, analyze memory bandwidth usage and memory latency, or even replace complete cores with software simulations running on the computer09:46
lekernelthis sort of things09:47
azonenbergI want to play with that at some point too09:47
lekernelall doable with a < 5 lines of code diff to your system09:47
azonenbergMake a bridge over jtag that connects my NoC to the PC09:47
azonenbergso i can have emulated and softcore nodes speaking freely09:47
azonenbergsystem-level hardware cosimulation :D09:49
lekernelit can work really nice with those "pytholite" compiled actors. when debugging you can run the suspicious actor on the computer and use print() etc. - then you just put it back into hw when you have fixed the bugs09:50
azonenbergHmm, good idea09:50
azonenbergi need to play with verilog simulation more and see how to get it to bridge with native APIs09:50
azonenberglike, have a verilog module i instantiate in my simulation that bridges to C++ code or (indirectly) a hardware device09:50
azonenbergthis could massively speed up verification09:51
azonenbergi should have done this a long time ago09:51
azonenbergwriting C++ code to send stimuli to a module being exercised in hardware09:52
azonenbergwhle having an internal LA capture bus traffic that module generates09:52
lekernelwell the problem of doing it at the verilog level is you need to pause the FPGA basically at every cycle09:52
azonenbergNo, you misunderstand09:52
azonenbergThe integration would be done at the protocol level09:53
azonenbergmy NoC is based on a packet-switched fabric09:53
azonenbergso packets would be generated by the simulator or PC code, when fully transmitted they'd be sent over jtag to the DUT, then sent at full speed onto the wire09:53
lekernelah, yeah, so that's basically the same idea09:53
azonenbergi'm debating whether to make the jtag mux use the NoC too09:53
azonenbergbecause that would be cleaner but restrict usage somewhat09:54
azonenbergi might make two endpoints09:54
azonenberghave 16-bit addresses and you could have either a native front-end or a NoC front end09:54
azonenbergSo this is an early draft10:04
azonenbergbut does anyone have comments? http://colossus.cs.rpi.edu/~azonenberg/downloads/datasheet.pdf :p10:04
lekernel"allow nerd deployments to be customized to customer needs"10:18
lekernelthis almost sounds like something from dilbert :)10:19
azonenberglekernel: so i have my jtag software speaking to the fpga now via USER117:12
azonenbergthe first design decision i have to make is the semantics of the interface17:13
azonenbergshould i keep it JTAG-style with an IR and a DR for each peripheral?17:13
azonenbergi'm thinking maybe it'd be better to build it around packet switching17:13
wpwrakdo any modern-day datasheets actually use deg F ? :)17:23
azonenbergwpwrak: probably not, but i wasnt in the mood to convert17:24
azonenbergdid you get a laugh out of it otherwise? :P17:24
wpwrakand i kinda doubt that you can provide fully functional nerd units with only 9 months lead time :)17:24
azonenbergand no, they ship with blank disks17:25
azonenbergyou need years of firmware updates and configuration before they're usable17:25
azonenbergsomeone needs to port dd to nerdOS...17:25
azonenbergthen you can just drop in a new firmware image17:25
wpwrakyou could mention that the traditional bulk import of unscreened units has been suspended for the time being17:26
wpwraka dfu-capable brain would actually be quite useful :)17:27
larscuntil you brick it17:27
wpwrakhmm, and wouldn't 100% oxygen be potentially damaging ? fwiw, you may also include atmospheric pressure and humidity. plenty of environmental factors to consider :)17:33
wpwrakah, it's in the small letters ;-)17:33
azonenbergand yes, i am going to add a lot more stuff17:34
wpwraklarsc: i suppose you'd just unbrick it via dfu, no ? :)17:34
wpwrakjust install the latest backup17:34
Action: azonenberg plugs jtag cable into wpwrak's brain 17:34
wpwrakouch !17:34
azonenbergwpwrak: you cant feel it17:39
azonenbergfirst off, boundary scan doesnt affect normal device functioning17:39
azonenbergso until i start loading new memories into your brain or moving your fingers you wont notice anything out of the ordinary17:40
azonenbergsecond, the brain does not have any sensory nerve endings in it :p17:40
larscyea, quite funny, once you removed the skull you can keep poking the brain without people noticing it ;)17:42
larscwpwrak: that won't work if you bricked your own brain17:42
wpwrakazonenberg: it's more the obstacles on the way to the brain that i suspect would give me a bit of a headache17:44
azonenbergdetails, details :P17:44
wpwraklarsc: hmm, you have a point there. better have some one around to initiate the recovery17:44
azonenbergwpwrak: with any luck the TAP will still be functional17:47
--- Thu Nov 22 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!