| azonenberg | Anybody here work with the BSCAN primitive? | 09:09 |
|---|---|---|
| mumptai | the nor flash programmer of urjtag does, iirc | 09:10 |
| mumptai | (got to run) bye | 09:10 |
| azonenberg | i'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 FPGA | 09:11 |
| azonenberg | so that i can have say a gdb bridge and a bus sniffer both running simultaneously using the single jtag interface | 09:11 |
| azonenberg | via a packet-switched protocol using USER1 as an address, USER2 as the per-core IR, and USER3 as the per-core DR | 09:12 |
| azonenberg | so you basically have virtualized TAPs on each core | 09:12 |
| lekernel | azonenberg: http://www.milkymist.org/misc/ml401_flasher-1.0.tar.bz2 | 09:21 |
| lekernel | I wrote that a while ago | 09:22 |
| lekernel | it's for virtex4 though | 09:22 |
| azonenberg | lekernel: i'll take a look | 09:23 |
| azonenberg | does the system i mentioned sound useful? | 09:23 |
| azonenberg | i 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* instructions | 09:24 |
| azonenberg | it's going to be nice and generic, i'm going to support the Digilent API, openocd, and possibly raw ftdi adapters as back ends | 09:24 |
| lekernel | can you make it generic enough that GDB isn't an assumption anymore? | 09:35 |
| azonenberg | Yes | 09:35 |
| lekernel | i'd use something like that to measure memory bandwidth, dataflow token rates, etc. | 09:35 |
| azonenberg | The 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 |
| azonenberg | you will then use a simple frame-based format consisting of {opcode, length, data} or similar | 09:36 |
| azonenberg | for example "set IR to 16 bits 0xDEAD" | 09:36 |
| azonenberg | "set IR to 32 bits BAADC0DE and return result" | 09:36 |
| azonenberg | the idea is to use jtag as a link-layer protocol and define a socket-style transport layer on top | 09:37 |
| azonenberg | and then you can run any application-layer traffic you want on top of those connections | 09:37 |
| lekernel | also to control embedded logic analyzers | 09:37 |
| azonenberg | Yep | 09:37 |
| azonenberg | I intend to add a RED TIN module for it | 09:37 |
| azonenberg | It will also allow you to speak directly to the chip rather than to cores on it | 09:38 |
| azonenberg | to query serial numbers, do boundary scan, and Xilinx-specific commands for loading bitstreams etc | 09:38 |
| azonenberg | though you could of course add another class that derives from FPGA and JtagDevice other than XilinxSpartan6Device | 09:38 |
| azonenberg | It will support plug-and-play to the extent possible | 09:39 |
| azonenberg | automatically identifying FPGAs via IDCODE and then querying USER* instructions to see if one of my cores is present on it | 09:39 |
| azonenberg | and if so, finding out how many cores are present and getting ID codes off each | 09:39 |
| azonenberg | so 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 |
| azonenberg | So 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 discovered | 09:40 |
| azonenberg | you could thus have multiple LAs present | 09:40 |
| azonenberg | i dont think chipscope can do that :D | 09:40 |
| azonenberg | the big problem with chipscope though is that it doesnt play well with softcore ICD since i think it monopolizes the USER* instructions | 09:41 |
| azonenberg | this system would be built around multiplexing and sharing from the start | 09:41 |
| azonenberg | And by virtue of being socket based, remote config/debug comes almost for free | 09:41 |
| lekernel | and it's horrible java bloatware | 09:41 |
| azonenberg | Lol | 09:41 |
| azonenberg | RED TIn is still a bit buggy but is getting there, and is like 2000 lines of C++ and verilog :D | 09:42 |
| azonenberg | 1k of each roughly | 09:42 |
| azonenberg | lightweight, does exactly what it needs to and not a single thing more | 09:42 |
| lekernel | with 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 distance | 09:42 |
| azonenberg | Lol | 09:42 |
| azonenberg | while 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 it | 09:43 |
| azonenberg | i'm a big fan of minimalism in hardware/software design | 09:43 |
| lekernel | I'll want to improve in-system debugging support in migen at some point | 09:44 |
| azonenberg | well feel free to use this system | 09:45 |
| azonenberg | I'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 usable | 09:45 |
| azonenberg | it's already able to connect to my Atlys via the embedded Digilent programmer, probe the chain, and identify the chip as an XC6SLX45 rev 3 | 09:45 |
| lekernel | have 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 computer | 09:46 |
| lekernel | this sort of things | 09:47 |
| azonenberg | Nice | 09:47 |
| azonenberg | I want to play with that at some point too | 09:47 |
| lekernel | all doable with a < 5 lines of code diff to your system | 09:47 |
| azonenberg | Make a bridge over jtag that connects my NoC to the PC | 09:47 |
| azonenberg | so i can have emulated and softcore nodes speaking freely | 09:47 |
| azonenberg | system-level hardware cosimulation :D | 09:49 |
| lekernel | it 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 bugs | 09:50 |
| azonenberg | Hmm, good idea | 09:50 |
| azonenberg | i need to play with verilog simulation more and see how to get it to bridge with native APIs | 09:50 |
| azonenberg | like, have a verilog module i instantiate in my simulation that bridges to C++ code or (indirectly) a hardware device | 09:50 |
| azonenberg | this could massively speed up verification | 09:51 |
| azonenberg | i should have done this a long time ago | 09:51 |
| azonenberg | writing C++ code to send stimuli to a module being exercised in hardware | 09:52 |
| azonenberg | whle having an internal LA capture bus traffic that module generates | 09:52 |
| lekernel | well the problem of doing it at the verilog level is you need to pause the FPGA basically at every cycle | 09:52 |
| azonenberg | No, you misunderstand | 09:52 |
| azonenberg | The integration would be done at the protocol level | 09:53 |
| azonenberg | my NoC is based on a packet-switched fabric | 09:53 |
| azonenberg | so 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 wire | 09:53 |
| lekernel | ah, yeah, so that's basically the same idea | 09:53 |
| azonenberg | i'm debating whether to make the jtag mux use the NoC too | 09:53 |
| azonenberg | because that would be cleaner but restrict usage somewhat | 09:54 |
| azonenberg | i might make two endpoints | 09:54 |
| azonenberg | have 16-bit addresses and you could have either a native front-end or a NoC front end | 09:54 |
| azonenberg | So this is an early draft | 10:04 |
| azonenberg | but does anyone have comments? http://colossus.cs.rpi.edu/~azonenberg/downloads/datasheet.pdf :p | 10:04 |
| lekernel | "allow nerd deployments to be customized to customer needs" | 10:18 |
| lekernel | this almost sounds like something from dilbert :) | 10:19 |
| azonenberg | lol | 10:19 |
| azonenberg | lekernel: so i have my jtag software speaking to the fpga now via USER1 | 17:12 |
| azonenberg | the first design decision i have to make is the semantics of the interface | 17:13 |
| azonenberg | should i keep it JTAG-style with an IR and a DR for each peripheral? | 17:13 |
| azonenberg | i'm thinking maybe it'd be better to build it around packet switching | 17:13 |
| wpwrak | do any modern-day datasheets actually use deg F ? :) | 17:23 |
| azonenberg | wpwrak: probably not, but i wasnt in the mood to convert | 17:24 |
| azonenberg | did you get a laugh out of it otherwise? :P | 17:24 |
| wpwrak | and i kinda doubt that you can provide fully functional nerd units with only 9 months lead time :) | 17:24 |
| azonenberg | and no, they ship with blank disks | 17:25 |
| azonenberg | you need years of firmware updates and configuration before they're usable | 17:25 |
| azonenberg | someone needs to port dd to nerdOS... | 17:25 |
| azonenberg | then you can just drop in a new firmware image | 17:25 |
| wpwrak | you could mention that the traditional bulk import of unscreened units has been suspended for the time being | 17:26 |
| wpwrak | a dfu-capable brain would actually be quite useful :) | 17:27 |
| azonenberg | lol | 17:27 |
| larsc | until you brick it | 17:27 |
| wpwrak | hmm, 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 |
| wpwrak | ah, it's in the small letters ;-) | 17:33 |
| azonenberg | and yes, i am going to add a lot more stuff | 17:34 |
| wpwrak | larsc: i suppose you'd just unbrick it via dfu, no ? :) | 17:34 |
| wpwrak | just install the latest backup | 17:34 |
| Action: azonenberg plugs jtag cable into wpwrak's brain | 17:34 | |
| wpwrak | ouch ! | 17:34 |
| azonenberg | wpwrak: you cant feel it | 17:39 |
| azonenberg | first off, boundary scan doesnt affect normal device functioning | 17:39 |
| azonenberg | so until i start loading new memories into your brain or moving your fingers you wont notice anything out of the ordinary | 17:40 |
| azonenberg | second, the brain does not have any sensory nerve endings in it :p | 17:40 |
| larsc | yea, quite funny, once you removed the skull you can keep poking the brain without people noticing it ;) | 17:42 |
| larsc | wpwrak: that won't work if you bricked your own brain | 17:42 |
| wpwrak | azonenberg: it's more the obstacles on the way to the brain that i suspect would give me a bit of a headache | 17:44 |
| azonenberg | details, details :P | 17:44 |
| wpwrak | larsc: hmm, you have a point there. better have some one around to initiate the recovery | 17:44 |
| azonenberg | wpwrak: with any luck the TAP will still be functional | 17:47 |
| --- Thu Nov 22 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!