#emc-devel | Logs for 2007-04-03

[00:22:02] <jmkasunich> hi y'all
[00:22:08] <cradek> hey
[00:22:14] <jmkasunich> hey yourself
[00:23:19] <jmkasunich> how's things
[00:23:24] <cradek> fine fine
[00:23:29] <jmkasunich> cool
[00:23:37] <cradek> I'm thinking of crapping up axis some more while jepler's gone
[00:23:44] <jmkasunich> ;-)
[00:23:48] <jmkasunich> go for it
[00:23:52] <jmkasunich> he can only kill you once
[00:24:10] <cradek> you know I never thought of it that way.
[00:24:35] <SWPLinux> hiya folks
[00:24:36] <cradek> I don't know if he has the tenacity to kill me even once though
[00:24:47] <SWPLinux> well, he doesn't eat meat, so ...
[00:24:52] <SWPLinux> :)
[00:25:33] <cradek> I'm thinking about a way to let the user spawn an editor to edit the loaded program and the tool table
[00:25:45] <cradek> I can't decide where to put it though
[00:25:51] <jmkasunich> edit the loaded program? or edit on disk and then reload?
[00:25:53] <SWPLinux> tools ...
[00:26:14] <SWPLinux> right-click in the text area would be good for the loaded program
[00:26:13] <cradek> jmkasunich: only spawn an external editor
[00:26:26] <cradek> no, that's definitely out of the question
[00:26:30] <jmkasunich> so that means edit on disk, and then reload?
[00:26:33] <SWPLinux> from a context menu, not just a right-click
[00:26:33] <cradek> yes
[00:27:26] <cradek> maybe I should start with the tool table. that's less contentious
[00:27:30] <SWPLinux> in fact, it could be considered useful if the file menu items (at least those related to files) were available on a context menu
[00:27:47] <cradek> why?
[00:28:23] <SWPLinux> well, I think people (certainly Windows people, possibly Linux people) expect to get a context menu when they right-click
[00:28:38] <cradek> but why file items?
[00:28:39] <SWPLinux> and reload, open, or edit are valid things to do
[00:28:49] <jmkasunich> cause you clicked on the file
[00:28:50] <SWPLinux> since the text area shows the loaded file
[00:29:41] <SWPLinux> actually, everything but quit (plus edit) would make sense
[00:30:10] <SWPLinux> and "run from here" if you can detect the line that was clicked
[00:30:12] <jmkasunich> the one risk I see with the editor is that somebody will _think_ he's editing the file in memory, and not realize that he's changing the disk copy
[00:30:37] <SWPLinux> that's one reason why an external editor is actually preferable
[00:30:46] <jmkasunich> ?
[00:30:57] <SWPLinux> it'll be pretty^Wmore obvious that you're editing the disk file
[00:31:04] <jmkasunich> true
[00:31:17] <jmkasunich> but still, I see the following happening:
[00:31:22] <SWPLinux> especially when axis asks you if you want to reload it because it changed ;)
[00:31:23] <jmkasunich> user decides to change something
[00:31:48] <SWPLinux> sure - twiddle a spindle speed or feedrate and restart, and the disk file has changed = oops
[00:31:59] <jmkasunich> opens the editor, edits, saves, reloads, looks at preview "crap, thats not what I wanted" "where's the damned cancel button, I want to undo this edit"
[00:32:10] <SWPLinux> yep
[00:33:08] <SWPLinux> but since you need to explicitly save in the external editor, that shouldn't be aproblem
[00:33:24] <SWPLinux> in fact, if you leave the editor open, you may still be able to undo
[00:33:32] <jmkasunich> true
[00:34:08] <jmkasunich> that would be good - otherwise, a few days after the editor is added, they'll want to be able to preview their edits while they're editing
[00:34:17] <SWPLinux> heh
[00:34:31] <SWPLinux> I want to be able to drag a line in the preview and have it modify the G-code ;)
[00:34:42] <SWPLinux> (not!)
[01:08:05] <jmkasunich> well, I think I've figured out why I'm having such a problem resuming work on the 5i20
[01:08:37] <jmkasunich> the config issue is still messy - I can't think of a clean way to do it, and if I go much farther without a plan, I'm gonna have to redo a lot of stuff
[01:11:37] <SWPLinux> as it happens, I just took two courses: one on Verilog and one on VHDL
[01:12:05] <SWPLinux> not that that helps any :)
[01:12:28] <jmkasunich> yeah - the problem isn't the fpga, its the fact that its too damned flexible
[01:15:04] <SWPLinux> I'm about to head over to the lounge for a bite. do you have a short synopsis of the problem so I can think about it while eating?
[01:18:31] <jmkasunich> ok
[01:18:45] <jmkasunich> we can (and will) have multiple FPGA configs
[01:18:59] <jmkasunich> its not too hard to code data in the config to tell the driver what is there
[01:20:05] <jmkasunich> it gets worse when you have a config with say 8 stepgens and 8 encoders and 8 pwm, and you want to tell it "Use the first 4 stepgens, 2 of the PWMs, and 3 of the encoders, and make the rest general purpose I/O, of which I want 12 inputs and 15 outputs and stepgen 2 needs to be quadrature, and ....and... and..."
[01:22:20] <jmkasunich> there is a limit to what you can pass as insmod params (maybe not a technical one, but a user sanity imposed one)
[01:35:32] <SWPLinux> I/O can actually be HAL params, can't it?
[01:35:42] <SWPLinux> (ie, direction and inversion/pull-up)
[01:36:02] <jmkasunich> yes
[01:36:25] <jmkasunich> although exporting HAL pins for outputs that are being used for stepping isn't good
[01:36:36] <SWPLinux> would the PWMs/stepgens be overlapped?
[01:37:10] <SWPLinux> actually, exporting everything may be the best thing, but the driver would still need to know whether a pin is writable
[01:37:39] <jmkasunich> exporting everything makes lots of HAL pins, messy but tolerable
[01:37:50] <jmkasunich> but it also misleads the user about what can and can't be used
[01:38:03] <SWPLinux> true (ish)
[01:38:06] <jmkasunich> I like the fact that you can discover things using "show"
[01:38:30] <SWPLinux> yep - that's a good feature to not screw up needlessly
[01:39:35] <SWPLinux> so - I'm thinking of the various functional blocks as either
[01:39:46] <SWPLinux> "input functions" or "output functions"
[01:40:02] <jmkasunich> stepgen, pwmgen = output, encoder = input
[01:40:06] <SWPLinux> stepgen/PWM are output, encoder is input, I/O are in or out ...
[01:40:08] <SWPLinux> right
[01:40:53] <SWPLinux> so, if a config has 8 PWM and 8 stepgen, does that mean that there are 8 slots that can be either a stepgen or a pwmgen (using 16 pins total), or that you could use all 16 blocks simultaneously?
[01:41:05] <SWPLinux> (which would use 32 pins)
[01:41:15] <jmkasunich> at the moment, the pwm and stepgen don't conflict
[01:41:39] <SWPLinux> would you keep it that way, or would you prefer to have them "overlap"?
[01:41:56] <jmkasunich> someday when there is a 5i22, with 1.5 million gates, the boards will definitely be pin limited, and you might be able to chose between pwm, step, encoder, and who-knows-what for each pin pair
[01:42:18] <jmkasunich> peter has also talked about supporting some of the other step types, with more than 2 pins
[01:42:29] <SWPLinux> right - that would be useful, but a nightmare for wiring
[01:42:37] <SWPLinux> both HAL and physical wiring
[01:42:39] <jmkasunich> in that case, you might use stepgen 0, skip 1 (because 0 is using its pins), then use 2, etc
[01:43:12] <SWPLinux> well, there are two ways of not overlapping stepgens
[01:43:29] <SWPLinux> one is to only make 1 stepgen per 6 pins, so 4 per connector
[01:43:34] <jmkasunich> a nightmare unless you can tell the board "I want stepgen on pins 1 and 2, encoder on 3 and 4" - in that case, HAL will only export what you are using
[01:43:36] <SWPLinux> let's leave out the 5-phase up/down
[01:44:26] <SWPLinux> actually, that may make some sense - break things up into 6-pin (or whatever) blocks, rather than 2-pin blocks
[01:44:52] <SWPLinux> the disadvantage is that you end up with signals of a common type spread all over the connectors
[01:44:56] <jmkasunich> right
[01:45:02] <SWPLinux> ie, your 24 outputs are on all 3 connectors
[01:45:29] <SWPLinux> the other option is to use outputs 1+2 on all 3 connectors for the 6-pin function
[01:45:37] <jmkasunich> making the block size match the "device" with the most pins is a mess
[01:45:49] <SWPLinux> a simple stepgen/pwmgen only uses the first pair of pins, the rest are I/O
[01:46:07] <SWPLinux> so you get step/pwm on connector 1, and I/O on connectors 2+3
[01:46:29] <jmkasunich> wiring would be a mess if you were using the additional step types
[01:46:45] <SWPLinux> but then an encoder (expecially a differential encoder, if it can be supported) is a wiring nightmare
[01:46:56] <jmkasunich> differential is a non-issue
[01:47:02] <SWPLinux> right - 5-phase also becomes an issue
[01:47:11] <SWPLinux> or 4-phase ...
[01:47:16] <jmkasunich> the fpga shouldn't be doing differntial stuff, thats what line recievers are for
[01:47:22] <jmkasunich> but 3, 4, and 5 phase are a mess
[01:47:55] <SWPLinux> some FPGAs have differential receiver options, but I'm not sure if (a) that includes the Spartan 2 or (b) the pairs are near each other on the connectors
[01:48:09] <jmkasunich> I plan to have all 72 pins routed to input registers, and HAL can export pins for whatever subset the user wants
[01:48:44] <jmkasunich> you normally wouldn't export input pins for stuff that is being used for somethign else, unless you were debugging (halscope the encoder signals for example)
[01:49:15] <SWPLinux> do you think it's possible (and relatively reasonable) to make the FPGA configurable enough that you could redirect pins around as needed
[01:49:21] <jmkasunich> even the 5i20 is (IMO) I/O limited, and I wouldn't waste pins on differntial, I'd use a reciever chip
[01:49:34] <SWPLinux> ie, if I want a 5-phase stepgen then an encoder with index, then a few I/Os, then a PWM ...
[01:49:43] <jmkasunich> redirecting pins would make it worse, not better
[01:50:00] <SWPLinux> I'm wondering only about the FPGA, not the insmod parameters (for now)
[01:50:10] <jmkasunich> it would be "expensive"
[01:50:16] <SWPLinux> I'm not sure a full crossbar would be reasonably doable
[01:50:26] <jmkasunich> I'm sure it would not be doable
[01:50:31] <jmkasunich> muxes get expensive fast
[01:50:36] <SWPLinux> true
[01:50:50] <jmkasunich> even a 4 in mux is more than one clb (which sucks)
[01:51:02] <jmkasunich> more than one lut I mean
[01:51:12] <SWPLinux> sure - that has 6 inputs, the 4 mux inputs and the 2 selectors
[01:51:22] <SWPLinux> a 2-input mux should be one lut
[01:51:27] <jmkasunich> yep
[01:51:59] <jmkasunich> dealing with 15 step types would also be very expensive
[01:52:14] <SWPLinux> sure
[01:52:25] <SWPLinux> I'd say that the 5-phase types aren't needed
[01:52:25] <jmkasunich> the sw stepgen uses a 15x10x5 lookup table
[01:52:59] <jmkasunich> I had been planning on only providing the 2 phase ones - step/dir, up/down, and quadrature
[01:53:44] <SWPLinux> yep - that and PWM are all multiplexable
[01:54:10] <jmkasunich> step, up, phaseA, pwm, and gpout = 5 = messy
[01:54:45] <SWPLinux> should still be 2 LUTs
[01:54:51] <jmkasunich> for the config, I was thinking of something like list for each pin
[01:54:52] <SWPLinux> 5 inputs and 3 select bits
[01:55:05] <SWPLinux> there are just invalid select inputs
[01:55:44] <jmkasunich> pin5 might be: stepgen.2.step, stepgen.2.up, stepgen.2.phaseA, stepgen.0.phaseE, pwmgen.2.pwm, ...., ...., gp_out_5
[01:56:07] <jmkasunich> I don't think you can say "2 LUT = 8 ins"
[01:56:40] <jmkasunich> you have to route the select lines to each lut, not just one of them
[01:56:56] <SWPLinux> hmm - could be true, but there are usually extra connections between LUTs in a single CLB (carry being one of them)
[01:57:00] <SWPLinux> true
[01:58:06] <SWPLinux> I know in one architecture (not sure which), there's a separate input to the CLB to select which LUT output to use, so you get effectively one extra selector input without using any of the 4 LUT inputs
[01:58:06] <jmkasunich> anyway, counting luts is a bit of a digression...
[01:58:10] <SWPLinux> yes
[01:59:02] <SWPLinux> even if you need 8 LUTs per pin for muxing, there are only 72 pins, so it shouldn't be a big deal
[01:59:19] <SWPLinux> (but I guess I should look up the specs for this chip before saying that :) )
[01:59:30] <jmkasunich> * jmkasunich looks ;-)
[02:01:09] <jmkasunich> 4707 luts
[02:01:12] <SWPLinux> looks like 1176 LEs, but I'm not sure how many LUTs are in an LE
[02:01:21] <jmkasunich> 4704 I mean
[02:01:34] <SWPLinux> ok, looks like 4 per LE ;)
[02:02:27] <jmkasunich> 8 in mux would take 5 luts I think
[02:02:40] <jmkasunich> no, more
[02:03:12] <jmkasunich> 5*72 = 360
[02:03:28] <jmkasunich> about 8% of the device just for output routing :-(
[02:04:31] <SWPLinux> but that's a very big feature, and isn't replicated
[02:04:45] <SWPLinux> well, it's already replicated for the 72 pins
[02:04:47] <jmkasunich> true
[02:05:33] <SWPLinux> though I suspect that the extra logic in an LE might be able to handle an 8-input mux
[02:05:47] <SWPLinux> the extra stuff around each slice looks pretty complex
[02:06:11] <jmkasunich> so, we're back to the real dilemma
[02:06:19] <SWPLinux> in fact, they say so under the slice diagram
[02:06:26] <SWPLinux> page 11 of the PDF
[02:06:31] <jmkasunich> if you got 2, or 3, or 8 things that can come out of a pin, how do you tell the driver what you want
[02:06:47] <SWPLinux> one string, with letters for the functions you want
[02:07:25] <SWPLinux> possibly with a repeat count, so "3S2Q4E" is 3 stepgens, 2 quadrature outputs, 4 encoders
[02:07:41] <SWPLinux> then default all remaining pins to half in, half out (or something like that)
[02:08:11] <SWPLinux> use I and O (and i/o) for 8 bits of in/out or 4 bits for the lower case, like the 8255 driver
[02:08:40] <jmkasunich> so you wouldn't be saying "put a stepgen on pins 5 and 6", just "gimme a stepgen"
[02:08:50] <SWPLinux> you can also dump the numerical shorthand, and just require the above to be "SSSQQEEEE"
[02:09:00] <SWPLinux> right - it goes on the next 2 pins
[02:09:06] <jmkasunich> Q = stepgen with quadrature out?
[02:09:16] <SWPLinux> yep (in the example anyway)
[02:09:32] <jmkasunich> for step/dir, up/down, and quadrature that could work
[02:09:35] <SWPLinux> I'd make the granularity 2 pins
[02:09:39] <SWPLinux> maybe 4
[02:09:44] <jmkasunich> gonna run out of letters fast if we support other step types
[02:09:51] <jmkasunich> or other functional blocks
[02:10:06] <SWPLinux> well, if we have 8:1 muxes, we only need 8 letters ;)
[02:10:12] <jmkasunich> not true
[02:10:21] <SWPLinux> right - you could have different sets on different pins
[02:10:38] <jmkasunich> pins 1 and 2 might have a choice between step and pwm, pins 23 and 24 could have a completely differnt choice
[02:10:49] <SWPLinux> right
[02:11:02] <SWPLinux> the string approach allows the user to specify both what and where things go
[02:11:35] <SWPLinux> there are advantages and disadvantages though
[02:11:43] <jmkasunich> assuming they have both a map of what the possibilities in a particular FPGA are, and the decoder ring for the string syntax
[02:11:52] <SWPLinux> encoder ring ;)
[02:11:58] <jmkasunich> yeah
[02:12:20] <jmkasunich> I'm envisioning some program that serves as map and ring
[02:12:24] <SWPLinux> there would probably need to be a utility that could
[02:12:26] <SWPLinux> right
[02:12:48] <SWPLinux> read card setup and output the possibilities for that config
[02:12:57] <jmkasunich> basically what I want to do is architect that utility and how it communicates with the rest of the system (driver and FPGA)
[02:13:00] <SWPLinux> on a pin-pair basis
[02:13:03] <jmkasunich> then I can move forward
[02:13:05] <SWPLinux> right
[02:13:48] <jmkasunich> the FPGA will have a 256x32 ram/rom, the utility can load the config, read the rom to see the posibilities, then write it with the users choices
[02:14:06] <jmkasunich> the the driver (in kernel space) reads it to decide what to export
[02:14:46] <SWPLinux> I'd prefer to have the ability to set the config from the HAL file (though I guess loadusr could do that)
[02:15:34] <jmkasunich> I'm seeing the utility as interactive (discoverability again) with the ability to save the result for use the next time around
[02:15:55] <SWPLinux> that's great in some situations, terrible in others
[02:16:54] <jmkasunich> "$ fpga_tweak original_bitfile result_bitfile"
[02:17:08] <jmkasunich> pops up menus or whatever, and when you are happy, saves it
[02:17:19] <SWPLinux> what if I want to run keystick?
[02:17:26] <SWPLinux> ie, no X
[02:17:37] <jmkasunich> then "loadusr load_5i20_cfg result_bitfile; loadrt hal_5i2x"
[02:17:52] <SWPLinux> but it would be impossible to generate the config in the first place
[02:17:58] <jmkasunich> ncurses? ;-/
[02:18:00] <SWPLinux> heh
[02:18:51] <SWPLinux> I remember having this conversation before, but I don't remember all my good (or at least better) arguments against the idea of a separate program
[02:19:08] <jmkasunich> actually, fpga_tweak doesn't need to load the FPGA at all and could run on a machine with no 5i20 installed, if the config info was attached to instead of embedded in the bitstream
[02:19:16] <SWPLinux> I think I may have had you convinced at that time, but I don't know why :)
[02:19:29] <SWPLinux> true
[02:19:46] <jmkasunich> I think it was not so much convinced as depressed
[02:19:52] <SWPLinux> heh - could be
[02:19:57] <jmkasunich> you pointed out valid problems with my plan, but didn't have a much better one
[02:20:07] <SWPLinux> that's my MO these days :(
[02:20:33] <SWPLinux> I think a string module param could work, but it has to be well thought out
[02:20:37] <jmkasunich> interactivity is a goal for me - people never RTFM, and without it, a non-interactive tool will drive them nuts
[02:20:51] <SWPLinux> at worst, you would have a 72-char string, since there are 72 I/Os
[02:21:14] <jmkasunich> assuming that you can define all the possible options without running out of letters
[02:21:19] <SWPLinux> sure
[02:21:47] <SWPLinux> and that the letters you end up with make sense - S stands for Stepgen, SPI ...
[02:21:50] <jmkasunich> and assuming that the user reads the manual (which will be a bear, because it will have to somehow describe every possible combo)
[02:22:33] <jmkasunich> I wish the FPGA tools were Free instead of just free
[02:22:52] <jmkasunich> then I'd provide scripts or such to let people build the config they want, and it would be hardcoded
[02:22:53] <SWPLinux> actually, you can split things somewhat by having a couple of parameters: "outs" and "ins"
[02:22:55] <SWPLinux> heh
[02:23:21] <SWPLinux> so something like Q might be quadrature output or quadrature input, depending
[02:23:25] <jmkasunich> every bitfile would produce one and only one set of hal pins
[02:23:31] <jmkasunich> very discoverable
[02:23:43] <SWPLinux> yep - that would be one good solution
[02:23:57] <jmkasunich> the idea of attaching additional info to the bit file is along those lines
[02:24:15] <jmkasunich> every "augmented bitfile" would produce one and only one set of hal pins
[02:24:31] <SWPLinux> there's no reason for the data to be attached to the bitfile - you just need a naming convention for separate files
[02:24:49] <jmkasunich> and the augmentation would be done once by the integrator using the utility, instead of by editing VHDL and using the xilinx tools
[02:25:20] <jmkasunich> having seperate files gets messy
[02:25:37] <SWPLinux> twiddling with the bitfile is its own brand of messy, I think
[02:25:49] <jmkasunich> one bitfile might have 8 pwm, 8 step, 8 encoder, another has 16 stepgen and no encoders
[02:26:02] <jmkasunich> a config that wants 12 stepgen can only be used with the one
[02:26:08] <SWPLinux> it's elegant in that all the data is in one file, and the bitfile format is meant to have headers that can be ignored
[02:26:16] <jmkasunich> I wouldn't twiddle with the bitfile content - I'd use headers
[02:26:41] <SWPLinux> sure, but you can have H5i20_12S8P.bit and H5i20_12S8P.capabilities
[02:26:55] <SWPLinux> (or whatever)
[02:27:12] <jmkasunich> and then the user generated H5i20_12S8P_joes_config?
[02:27:27] <jmkasunich> messy
[02:27:37] <SWPLinux> or joe's config says "uses H5i20_12S8P.bit"
[02:28:18] <jmkasunich> I dunno
[02:28:32] <SWPLinux> yeah - 6 of one, sqrt(36) of the other
[02:29:03] <jmkasunich> we've digressed again - you were originally against the idea of an interactive config tool at all, now we're debating how to store its output
[02:29:13] <SWPLinux> heh - oops
[02:29:34] <SWPLinux> I did try (feebly) to steer back to parameters
[02:29:45] <SWPLinux> but only for a fgew seconds
[02:29:53] <jmkasunich> I understand the desire to do it all in the driver
[02:30:03] <jmkasunich> but I just think it will drive folks insane
[02:30:41] <SWPLinux> some folks will be driven insane by having to use an external tool
[02:30:52] <SWPLinux> but as I said, I can't really remember all the reasons why
[02:30:53] <jmkasunich> I think it will drive me insane - I'm gonna have my own config (probably) with stepgens, encoders, and at least one special 3-phase pwmgen (6 outputs, to drive the 6 switches of a 3-phase bridge)
[02:31:56] <SWPLinux> there's no reason why each element has to be exactly one letter
[02:32:03] <SWPLinux> (or number)
[02:32:12] <jmkasunich> lets back up just a sec and break this down
[02:32:15] <SWPLinux> ok
[02:32:33] <jmkasunich> I think we have three differnet steps of "information transfer", and maybe we're squishing them all into the same mold
[02:33:04] <jmkasunich> 1) from the VHDL (or some other doc at that stage) to the user "here's the options for this particular bitfile"
[02:33:35] <jmkasunich> 2) from the user to the fpga "here's the options I want to use"
[02:33:44] <jmkasunich> 3) from the fpga to the driver "here's what you should export"
[02:33:59] <jmkasunich> you are talking about merging 2 and 3, using params to go direct from user to driver
[02:34:16] <SWPLinux> essentially
[02:34:17] <jmkasunich> I want to do 2 and 3, and store that info in/with the fpga
[02:34:45] <jmkasunich> the interactive tool addresses 1, I don't know how you'd do that otherwise
[02:35:02] <SWPLinux> the FPGA would have registers/ROM that the driver/utility can read
[02:35:27] <jmkasunich> not the driver
[02:35:41] <jmkasunich> all the driver can do is read the rom and say "what you asked for I can't do"
[02:35:53] <jmkasunich> we need something that tells the user what he can ask for
[02:35:59] <jmkasunich> (and how to ask)
[02:36:00] <SWPLinux> sure
[02:36:25] <SWPLinux> the driver could always export params with the number of X available
[02:36:37] <jmkasunich> nope
[02:36:45] <SWPLinux> hal_5i20.num_stepgens
[02:36:48] <SWPLinux> why not?
[02:37:04] <jmkasunich> because once you say "ok, I can have 8, but I only need 4", then what?
[02:37:22] <SWPLinux> well, you know that 4 is less than 8, so you can get what you want
[02:37:25] <jmkasunich> at that point, init is complete, and all 8 stepgen's worth of HAL pins have already been created
[02:37:34] <jmkasunich> plus 8 pwmgens and 8 encoders worth of HAL pins
[02:38:00] <jmkasunich> the info needed to decide what HAL pins to export needs to be available during init, not based on params that are created at init and modified later
[02:38:08] <SWPLinux> there's a two-step process no matter what, the question is how many tools you need, and what they look like
[02:38:46] <jmkasunich> oh, you are saying "step 1, load the bitfile, load the driver, and read dmesg, step 2, build a config string from the info in dmesg" ?
[02:38:50] <SWPLinux> if the driver would export nothing but the function list when loaded with no config string, then halcmd/halshow can tell you what's available
[02:39:28] <jmkasunich> that puts a bunch of user targeted stuff in a kernel space driver
[02:39:45] <jmkasunich> I'd rather do it in user space
[02:39:50] <SWPLinux> there can also be a utility that can tell the user the same information
[02:39:57] <jmkasunich> perhaps the loader utilty can do it - we need that anyway
[02:40:18] <jmkasunich> load bitfile into fpga (does this anyway), read rom, print notes to user
[02:40:26] <SWPLinux> I don't think I'm opposed to a utility of some sort, but I don't like the idea of reprogramming the FPGA and fiddling with the bitfile whenever something changes
[02:40:42] <SWPLinux> something = user config change
[02:40:44] <jmkasunich> well thats why I wanted to separate steps 1, 2, and 3
[02:40:58] <jmkasunich> step 1 = tell the user his options
[02:41:18] <jmkasunich> when you say "reprogramming the FPGA" what do you mean exactly?
[02:41:20] <SWPLinux> we both agree that's needed, even if it's the programmer (maker of the bitfile) creating a readme
[02:41:28] <jmkasunich> nothing I've proposed would alter the bitstream
[02:41:36] <SWPLinux> I mean "installing the config information into the FPGA"
[02:41:46] <SWPLinux> ie, selected config info
[02:42:20] <jmkasunich> so you would use the FPGA ROM strictly for step 1 - tell the user what he can choose, and maybe even not for that (use a readme instead) ?
[02:42:41] <SWPLinux> hold on - we're talking about steps 1 and 2 here
[02:42:42] <SWPLinux> interleaved
[02:42:54] <jmkasunich> not me
[02:42:55] <jmkasunich> just 1
[02:43:08] <SWPLinux> ok, then reprogramming is out of the conversation
[02:43:08] <jmkasunich> info from the VHDL author to the user
[02:43:35] <SWPLinux> right - that comes from the ROM
[02:43:39] <jmkasunich> it can be a readme, or it can be bits in the rom, parsed and output by a util
[02:43:42] <SWPLinux> right
[02:43:50] <jmkasunich> THEN you have step 2 (and maybe 3)
[02:43:56] <SWPLinux> yes
[02:44:01] <jmkasunich> getting the users info to the driver
[02:44:24] <SWPLinux> right - the user selections to the FPGA and driver, and subsequently from the driver to HAL
[02:44:33] <jmkasunich> that is the "write it in the rom" vs "use insmod params" debate
[02:44:40] <SWPLinux> yes
[02:45:12] <SWPLinux> you had found a utility to stick a particular memory map into a specific ROM space in the bitfile, right?
[02:45:18] <jmkasunich> yes and no
[02:45:37] <SWPLinux> ok (writing the ROM doesn't really parse well for me ;) )
[02:45:43] <jmkasunich> do you mean at FPGA compile (place & route) time, or later?
[02:45:55] <jmkasunich> there is no such thing as rom really
[02:46:01] <SWPLinux> later, as in your step 2 with an external utility
[02:46:11] <jmkasunich> its a ram, but the fpga can make it writable or not
[02:46:31] <SWPLinux> ok
[02:46:57] <jmkasunich> if I was gonna modify it, I would simply write to the ram after loading the fpga config
[02:47:14] <SWPLinux> ok, then flip the RO bit
[02:47:31] <jmkasunich> yeah, if desired
[02:48:11] <jmkasunich> basically, I was thinking of two different sets of data being in the ram
[02:48:23] <jmkasunich> 1) capabilities
[02:48:34] <jmkasunich> 2) user choices
[02:48:57] <jmkasunich> the util would read 1, talk to the user, and write 2
[02:49:05] <jmkasunich> the driver would read 2 and export stuff
[02:49:49] <SWPLinux> yeah. I guess that as long as the utility has a silent mode (like emc configname bypassing pickconfig), then that would be OK
[02:50:21] <SWPLinux> since you could load a set of selections with a loadusr line in the ini or a hal file
[02:50:29] <jmkasunich> the problem with what I just outlined is that 2 is stored only in the ram, and goes away on power down
[02:50:53] <SWPLinux> right - the utility needs to be run every time you start EMC
[02:51:06] <SWPLinux> just in case
[02:51:24] <jmkasunich> thats not the problem - A utility has to run every time, to load the FPGA from the bitfile
[02:51:36] <jmkasunich> the problem is that the util has to ask the user questions every time
[02:51:42] <jmkasunich> that is totally unacceptable
[02:51:43] <SWPLinux> only if necessary - there is a write cycle limit, and it takes time to do it
[02:51:50] <jmkasunich> what?
[02:51:55] <SWPLinux> program the FPGA
[02:52:07] <jmkasunich> what write cycle limit?
[02:52:15] <SWPLinux> EEPROM on the card
[02:52:20] <jmkasunich> there is no EEPROM
[02:52:31] <jmkasunich> this is a static ram based Xilinx FPGA
[02:52:37] <SWPLinux> hmmm. I thought the FPGA config was persistent across power-down
[02:52:41] <jmkasunich> when you power up the PC it is blank
[02:52:51] <jmkasunich> nope, you gotta load a bitfile
[02:52:58] <SWPLinux> are you absolutely sure of that?
[02:53:14] <jmkasunich> (there IS an EEPROM, but it holds config info for the PCI bridge chip - nothing at all to do with the FPGA)
[02:53:32] <SWPLinux> I could have sworn that there was an 8-pin FPGA config EEPROM on there
[02:53:35] <SWPLinux> hmmm
[02:53:40] <jmkasunich> I'm absolutely sure
[02:53:44] <SWPLinux> ok
[02:53:54] <jmkasunich> its for the 9030 bridge chip
[02:54:01] <SWPLinux> yep. I know about that one
[02:54:59] <jmkasunich> * jmkasunich looks at his 2nd board
[02:55:04] <jmkasunich> one FPGA
[02:55:11] <jmkasunich> one PLX9030
[02:55:22] <jmkasunich> one crystal
[02:55:28] <jmkasunich> one 2.5V regulator
[02:55:33] <jmkasunich> one 3.3V regulator
[02:55:46] <jmkasunich> one soic 8 that I can't read
[02:56:06] <jmkasunich> oh, there is another soic 8 that I can't read
[02:56:14] <jmkasunich> * jmkasunich looks for magnification
[02:57:08] <jmkasunich> ok, the first one I saw is CR12, an LM431, and is probably something of an analog nature
[02:57:17] <jmkasunich> ps monitor, regulator, dunno
[02:57:52] <jmkasunich> the other one is U5, a 93L something (its got green paint on it obscuring the rest of the number)
[02:57:56] <SWPLinux> ok - the manual says that the configuration has to be downloaded before you can do anything
[02:58:05] <jmkasunich> U5 is next to the 9030 chip
[02:59:00] <jmkasunich> ok, where were we ;-)
[02:59:19] <jmkasunich> <jmkasunich> thats not the problem - A utility has to run every time, to load the FPGA from the bitfile
[02:59:19] <jmkasunich> <jmkasunich> the problem is that the util has to ask the user questions every time
[02:59:19] <jmkasunich> <jmkasunich> that is totally unacceptable
[02:59:55] <SWPLinux> <SWPLinux>yeah. I guess that as long as the utility has a silent mode (like emc configname bypassing pickconfig), then that would be OK
[02:59:57] <jmkasunich> so, the users answers need to be stored somewhere non-volatile (which basically means on disk)
[03:00:15] <jmkasunich> the util can't be silent if it doesn't have the users answers tho
[03:01:04] <jmkasunich> I guess it could be "load_5i20 stock_bitfile my_ram_content"
[03:01:07] <SWPLinux> sure, but an error exit should stop the runscript, no?
[03:01:50] <jmkasunich> if you provide "my_ram_content", it loads the bitfile, then writes the ram content to the ram
[03:02:23] <jmkasunich> if you don't provide content, it loads the bitfile, _reads_ the ram content, uses it to tell you your options and ask you what you want
[03:02:36] <jmkasunich> then writes your answers to ram and to "my_ram_content"
[03:03:43] <SWPLinux> I guess it would make sense to determine how complex the "what I want" specifications will need to be
[03:03:58] <jmkasunich> and the "what are your options"
[03:04:11] <SWPLinux> ie, if I want 3 stepgens, can I decide that they should be numbers 6,7, and 8?
[03:04:23] <jmkasunich> I'm certain that it will fit in 256x32 better than it will fit in insmod params
[03:04:28] <SWPLinux> and would they then be stepgen.6-8, or would those be stepgen.0-2?
[03:04:45] <jmkasunich> I think you should be able to choose which stepgen you get, not just how many
[03:05:08] <SWPLinux> or pwmgen,encoder,pwmgen,encoder ...
[03:05:09] <jmkasunich> and I probably would use the 6-8 numbers, to simplify mapping between HAL channel numbers and physical pins
[03:05:38] <SWPLinux> yep - this could bring up another discussion we've had, regarding the PPMC driver :)
[03:05:50] <jmkasunich> not going there
[03:05:52] <SWPLinux> heh
[03:05:54] <jmkasunich> noway, nohow
[03:06:33] <jmkasunich> I've been thinking of the util as having 72 little menus, one per pin
[03:06:36] <SWPLinux> hmmm. actually, this has to be done your way - there's no reasonable way to tell the driver how to configure more than one board
[03:06:52] <SWPLinux> even if there is a reasonable way to tell it how to configure one board
[03:07:28] <jmkasunich> "do you want this pin to be A) gpout 24 B) stepgen.3.step C) stepgen.3.up, D) ....."
[03:08:21] <jmkasunich> thats true - if the config is in the ram, its a non-issue
[03:08:30] <SWPLinux> right
[03:09:05] <jmkasunich> remember when I said "load_5i20 the_bitstream my_choices" ?
[03:09:11] <SWPLinux> it may be better to separate the config options "logically" rather than phsically
[03:09:13] <SWPLinux> yes
[03:09:22] <jmkasunich> my original plan was to make "my_choices" a header in the bitstream
[03:09:30] <jmkasunich> but I now think the two file approach is fine
[03:09:45] <SWPLinux> ok - that may have been one of the convincing arguments before
[03:10:03] <SWPLinux> also, choosing to use one card or another (ie, clear the config on one card) would be a good option
[03:10:09] <jmkasunich> no, I never seriously considered a multi-file option until you mentioned it earlier this evening
[03:10:20] <SWPLinux> ok
[03:10:28] <SWPLinux> one day, I'll search the archives ;)
[03:10:29] <jmkasunich> yeah, even today, the load util takes a "which card" number
[03:11:13] <SWPLinux> right, but if I have two machines attached to one computer (say a lathe and a mill), and they're connected to different cards, I may want to use only one of the cards
[03:11:51] <jmkasunich> lathe: loadusr load_5i20 -n 0 a_bitstream lathe_custom_stuff
[03:11:52] <SWPLinux> and I don't want 5i20.0.stepgen.0 in one case and 5i20.1.stepgen.0 in the other (at least, I think I don't)
[03:12:07] <SWPLinux> sure, and clear -n 1 ...
[03:12:10] <jmkasunich> mill" loadusr load_5i20 -n 1 bitstream mill_custom_stuff"
[03:12:13] <jmkasunich> oh, I see
[03:12:27] <SWPLinux> that may be a useful insmod parameter
[03:12:35] <jmkasunich> you don't want any thing exported from the fpga you aren't using
[03:12:41] <SWPLinux> right
[03:12:58] <jmkasunich> that would be an insmod thing
[03:13:11] <jmkasunich> loadrt hal_5i2x boards=0
[03:13:13] <SWPLinux> and I think I'd prefer that the numbering start at the first used card, not the "slot number" or whatever
[03:13:15] <jmkasunich> loadrt hal_5i2x boards=0,1
[03:13:40] <jmkasunich> yeah, in fact that an advantage of the "boards=" thing
[03:13:43] <SWPLinux> you can have up to 4 boards, right?
[03:13:54] <jmkasunich> loadrt hal_5i2x boards=1,0 would swap everything easily
[03:14:09] <SWPLinux> right - specify the board number to use for each possible board, and -1 for unused
[03:14:13] <jmkasunich> I you can have as many boards as you have PCI slots
[03:14:30] <SWPLinux> I think there's a pair of config jumpers for hte board number though, isn't there?
[03:14:48] <SWPLinux> if not, then PCI enumeration order can screw up everything
[03:14:53] <jmkasunich> no
[03:15:02] <jmkasunich> you are thinking of the motenc I think
[03:15:03] <SWPLinux> I must be thinking of motenc or something ;)
[03:15:30] <jmkasunich> I don't think the -1 would be needed for boards=
[03:15:53] <jmkasunich> the first number is the board that will be m5i20.0.blah
[03:16:04] <jmkasunich> the 2nd number is the board that will be m5i20.1.blah
[03:16:15] <jmkasunich> if you only want one board, you only give one number
[03:16:43] <SWPLinux> ok, that sounds reasonable (as long as they default to something like -1 in the driver)
[03:16:53] <jmkasunich> yeah
[03:17:34] <jmkasunich> and the first -1 would terminate the list - no fair doing boards=1,-1,-1,0 to get m5i20.0 and m5i20.3
[03:18:05] <jmkasunich> or maybe that is legal, I dunno
[03:18:09] <jmkasunich> its a detail
[03:18:11] <SWPLinux> right - you wouldn't need to since you could do boards=0,3 instead
[03:18:16] <SWPLinux> right
[03:18:48] <jmkasunich> the way I was doing it, boards=0,3 would mean that the 4th board in the PC became m5i20.1
[03:19:00] <jmkasunich> not that the 2nd board in the PC became m5i20.3
[03:19:00] <SWPLinux> ah - true
[03:19:14] <jmkasunich> althought either way seems reasonable - just need to pick one (later)
[03:19:55] <SWPLinux> baords=0x10,0x03 (BCD with "slot number" then "HAL number" :) )
[03:20:04] <jmkasunich> heh
[03:20:07] <SWPLinux> NOT!
[03:20:30] <jmkasunich> we've digressed again
[03:20:33] <SWPLinux> the enumeration thing could be a problem
[03:20:50] <jmkasunich> you mean PCI mucking with things?
[03:20:52] <SWPLinux> add a board, and suddenly the one that's been in there for a year gets a different number
[03:20:54] <SWPLinux> yes
[03:21:09] <SWPLinux> it's the USB problem all over again
[03:21:14] <jmkasunich> lemme check something...
[03:21:20] <SWPLinux> (actually, it was a PCI problem first)
[03:22:24] <jmkasunich> it would be ok as long as PCI didn't reverse the order
[03:22:36] <jmkasunich> if you had something, 5i20, something_else, 5i20
[03:22:54] <SWPLinux> no, since you don't know what the order will be until you plug in another card
[03:23:13] <SWPLinux> slot 1 (if it's even labeled on the MB) may be the last one initialized
[03:23:18] <jmkasunich> you mean the two 5i20s might swap places?
[03:23:30] <SWPLinux> you wouldn't even know that until you plug in another one
[03:23:47] <SWPLinux> it may depend on the PCI driver
[03:24:07] <SWPLinux> that stuff has swapped around before (I recall some issues with Adaptec PCI SCSI controllers)
[03:24:21] <jmkasunich> well, theres nothing we can do about that
[03:24:23] <jmkasunich> so lets not digress
[03:24:32] <SWPLinux> but that's not the issue. I'd expect things to be relatively stable for a given hardware config
[03:24:46] <SWPLinux> sure - the board reordering option is a good one in that case
[03:25:03] <SWPLinux> in any case - the config tool ...
[03:25:33] <jmkasunich> if you really need to be safe, pick one pin number that is input on both boards, tie it high on one and low on the other, and wire hal logic to keep the machine from running if they aren't right
[03:25:36] <SWPLinux> I'm not sure it makes a lot of sense to allow (require) the user to select stepgen.0.step and stepgen.0.dir separately
[03:25:44] <SWPLinux> heh
[03:26:10] <SWPLinux> use the LEDs to indicate the board number
[03:26:21] <jmkasunich> I agree that its a little less natural than saying "turn on stepgen 0"
[03:26:30] <SWPLinux> they're useless in normal operation anyway (and therefore may not need to be exported to HAL)
[03:26:48] <SWPLinux> do you think anyone would want to use just step or just dir?
[03:26:53] <jmkasunich> no
[03:27:06] <SWPLinux> ok, then I'd select a function for the pin pair at once
[03:27:10] <jmkasunich> but I'm trying to make sure the config tool doesn't explode in complexity
[03:27:28] <SWPLinux> the FPGA would also have to explode to make that necessary
[03:27:40] <jmkasunich> its pretty easy to have 72 menues, each of which has 1 to 8 options, where the options are listed in the ram
[03:28:15] <SWPLinux> unless the pins can be shuffled (ie, stepgen.0 might show up almost anywhere), I don't think the config tool would be too horrendous
[03:28:17] <jmkasunich> its not so easy to deal with some "things" that might be 2 pins, some that might be 3, 4, etc
[03:28:57] <SWPLinux> the options won't be listed by name in the RAM, so the tool needs to know what the codes mean anyway
[03:29:09] <jmkasunich> pin-to-pin interactions seem to make things more complex tho
[03:29:20] <SWPLinux> it may as well know that a "function 3" uses 2 pins and "function 7" uses 4
[03:29:54] <SWPLinux> in addition to the fact that "function 3" should be represented to the user as "stepgen"
[03:30:01] <jmkasunich> not just stepgen
[03:30:10] <jmkasunich> stepgen with step/dir outputs
[03:30:16] <SWPLinux> sure
[03:30:25] <SWPLinux> or quadgen or pdmgen ...
[03:30:26] <jmkasunich> stepgen with three phases is a different number
[03:30:39] <jmkasunich> differnt function I mean
[03:30:42] <SWPLinux> yes, and has a different text string and a different pin quantity
[03:30:43] <jmkasunich> with a differnt number of pins
[03:30:58] <jmkasunich> lots of interaction tho
[03:31:23] <jmkasunich> suppose I have two consecutive stepgens (2 pins apart)
[03:31:36] <SWPLinux> well, let's consider the actual contents of the FPGA config RAM
[03:31:42] <jmkasunich> ok
[03:31:54] <jmkasunich> in fact, thats probably the most important thing for us to do
[03:32:18] <SWPLinux> for each possible pin function, there will be some few bits telling what function it is, another few bits telling what instance it is, and some others for ???
[03:32:44] <SWPLinux> function being "3-phase PWM" or "quadrature encoder" ...
[03:33:07] <jmkasunich> hmm
[03:33:10] <SWPLinux> I guess another bitfield would be the pin within the function (step, dir, QuadA, Index ...)
[03:33:11] <jmkasunich> again we have two kinds of data
[03:33:23] <jmkasunich> possibilities to be presented, and choices that were made
[03:33:41] <SWPLinux> I'm thinking only of possibilities right now
[03:33:43] <jmkasunich> only the latter really needs to be in the ram, so the driver can read it
[03:34:06] <jmkasunich> (although I'd like the former to be in ram too)
[03:34:18] <SWPLinux> I think the utility should be able to read from the config
[03:34:25] <SWPLinux> err - read the possibilities from the FPGA
[03:34:28] <jmkasunich> yes
[03:34:57] <SWPLinux> the ROM is 256x32 bits?
[03:35:00] <jmkasunich> yeas
[03:35:14] <SWPLinux> ok
[03:35:51] <SWPLinux> only I/O can go over 64 "instances" - it may be reasonable to limit the instance numbers to some small set of bits, like 4 or 5
[03:36:01] <jmkasunich> yeah
[03:36:03] <SWPLinux> I/O numbering is implicit anyway
[03:36:30] <SWPLinux> I'd think that 16 of a particular function should be sufficient
[03:36:31] <jmkasunich> yeah, we don't even need to list "GP output" as a possibility, its implied
[03:36:50] <SWPLinux> "none" may also be desirable (FWIW)
[03:37:23] <jmkasunich> as a choice that was made, yes, as a possiblity, no (I don't think)
[03:37:43] <jmkasunich> the first thing into the FPGA will be generic in/out logic for every pin
[03:37:51] <jmkasunich> so it will always be a possibility
[03:38:00] <SWPLinux> just to keep the HAL pin list shorter, I think
[03:38:15] <jmkasunich> agreed - none as a user choice is important
[03:38:25] <jmkasunich> but the utility can add that to the lsit
[03:38:26] <jmkasunich> list
[03:38:30] <SWPLinux> right
[03:38:42] <jmkasunich> I have a hunch the possiblities list is gonna get large fast
[03:38:58] <jmkasunich> 4 bits for "instance number"
[03:39:06] <SWPLinux> though that gets turned into an input, and the driver has to see that the pin is not to be exported (should be easy with a couple of bitmask words)
[03:39:09] <jmkasunich> 4 bits (maybe more) for "type of thing"
[03:39:31] <SWPLinux> add 4 bits for "pin name within this type of thing"
[03:39:32] <jmkasunich> do/do not export an input pin is an independent choice
[03:39:39] <jmkasunich> yes
[03:39:50] <jmkasunich> 12 bits so far
[03:39:53] <SWPLinux> so we're at 12 bits per pin so far
[03:39:59] <SWPLinux> per pin function, actually
[03:40:13] <jmkasunich> yeah, thats the thing
[03:40:22] <jmkasunich> once you've chosen, 12 bits per pin is easy
[03:40:33] <jmkasunich> but if you have 8 choices, at 12 bits each, per pin, gets big
[03:40:35] <jmkasunich> * jmkasunich calcs
[03:40:38] <SWPLinux> 7200
[03:40:40] <SWPLinux> ish
[03:40:44] <jmkasunich> 6912 ;-)
[03:40:49] <jmkasunich> we have 4096
[03:41:00] <SWPLinux> 256x32?
[03:41:03] <SWPLinux> that's 8192
[03:41:13] <jmkasunich> duh
[03:41:15] <SWPLinux> heh
[03:41:22] <jmkasunich> its 4k per block, and peter used 2 blocks
[03:41:45] <jmkasunich> a block is 256x16 (or various deeper but narrower configs)
[03:41:52] <SWPLinux> ok
[03:41:55] <jmkasunich> he wanted x32, hence 2
[03:43:07] <SWPLinux> aren't there more blocks available?
[03:43:16] <jmkasunich> I think so
[03:43:32] <jmkasunich> 14 maybe?
[03:43:34] <jmkasunich> total
[03:43:38] <jmkasunich> 12 left
[03:44:08] <SWPLinux> ok - and the PLX9030 can deal with more than 256x32 I assume (or do we not want to mess with that?)
[03:44:40] <jmkasunich> the PLX gives the FPGA either 64K bytes (16K x 32) or 64K x 32, I'm not sure which
[03:44:51] <jmkasunich> the FPGA's decode logic breaks that up further
[03:45:08] <jmkasunich> the ram is one 256x32 chunk, the rest is stepgens and all the other good stuff
[03:45:23] <SWPLinux> ok
[03:47:05] <jmkasunich> so we're looking at 12ish bits to tell the driver what we have chosen for a pin
[03:47:30] <jmkasunich> and somewhere between 3 and 8 times that much to list the possibiltiies
[03:47:41] <SWPLinux> no, you only need the 3 bits for the mux. the driver should be able to figure out what the pin function is from that
[03:48:07] <jmkasunich> still need the "thing type"
[03:48:10] <jmkasunich> (at a minimum)
[03:48:26] <jmkasunich> oh, duh
[03:48:41] <jmkasunich> I see - you want the driver to look up the code in the possibilties table
[03:48:52] <SWPLinux> yep
[03:49:00] <jmkasunich> possibiltiy[pin][choice]
[03:49:06] <jmkasunich> where choice = 0-7
[03:49:11] <SWPLinux> yep
[03:49:18] <jmkasunich> there are a few more bits per pin
[03:49:30] <SWPLinux> well, you need the mux per pin nayway ...
[03:49:34] <SWPLinux> anyway
[03:49:33] <jmkasunich> one to say "regardless of anything else, export an input pin"
[03:49:52] <jmkasunich> one to say "make this output open collector"
[03:50:12] <jmkasunich> (especially important for driving 5V stuff)
[03:50:57] <SWPLinux> we have around 17 extra bits per pin for that kind of thing
[03:50:58] <jmkasunich> one to say "invert this pin" for stuff like geckos that wants active low step pulses
[03:51:22] <SWPLinux> err - 17 bits inlcuding the 3 mux bits
[03:51:34] <jmkasunich> the m5i22 is gonna have 4 cables at 24 pins each, total of 96
[03:51:45] <jmkasunich> it would be nice if that could be accomadated
[03:51:59] <SWPLinux> I'm not sure every pin needs 8 functions
[03:52:19] <jmkasunich> almost certainly not - but packing them gets complex again
[03:52:42] <jmkasunich> 12 bit codes don
[03:52:51] <jmkasunich> don't fit well in 32 bit words either
[03:52:57] <SWPLinux> each connector may have 8, 6, or 4 (or some other number) functions
[03:53:00] <SWPLinux> per pin
[03:53:21] <SWPLinux> the "chosen config" info can go into the upper 4 bits per 16-bit word
[03:53:40] <SWPLinux> actually, it fits great
[03:54:01] <SWPLinux> first 32-bit word = instance numbers for each of the 8 functions
[03:54:02] <jmkasunich> I don't see that
[03:54:20] <jmkasunich> * jmkasunich listens
[03:54:40] <SWPLinux> second 32-bit word = 8 nibbles with the pin function number for each of the 8 options
[03:55:05] <jmkasunich> ah, you are unpacking them
[03:55:08] <SWPLinux> yep
[03:55:19] <SWPLinux> stack nibbles instead of spreading them out
[03:55:36] <steve_stallings> steve_stallings is now known as steves_logging
[03:55:44] <jmkasunich> actually we might be able to drop the instance numbers
[03:55:48] <SWPLinux> so each 3 dwords is a perfectly packed set of pin descriptions
[03:56:01] <SWPLinux> I was thinking that - they start at 0 and go up from there :)
[03:56:01] <jmkasunich> they could be assigned in sequence based on reading the thing-type and pin-type
[03:56:23] <SWPLinux> as long as there's no interleaving (wven that could work, but it's more of a pain)
[03:56:31] <SWPLinux> s/wven/even/
[03:56:42] <jmkasunich> I'm not sure a nibble is enough for a thing-type though
[03:57:06] <jmkasunich> if we did choose to support many step types, that would consume the available codes right quick
[03:57:22] <SWPLinux> true
[03:57:47] <jmkasunich> this is where your idea of doing it per thing vs. per pin is nicer - less duplication of thing type codes
[03:58:08] <SWPLinux> I suspect that no individual function (other than 5-phase PWM) needs more than 8 pins, so the type code and pin code can be 5+3 instead of 4+4
[03:58:45] <SWPLinux> up to 32 functions with up to 8 pins each
[03:59:01] <jmkasunich> how about 8+0 ;-)
[03:59:20] <jmkasunich> if the pins are always in sequence, then the pin codes increment
[03:59:41] <SWPLinux> hmmm
[03:59:53] <jmkasunich> I guess that does limit you though
[04:00:00] <SWPLinux> that requires more knowledge in the config utility and the driver
[04:00:18] <SWPLinux> the idea was to have some of this stuff discoverable by the tools
[04:00:21] <jmkasunich> yeah, and more important, it constrains your pinout
[04:00:38] <jmkasunich> I want to make sure that for example our pwmgens are pinned out to match a 7i33 board
[04:00:51] <jmkasunich> even if that means out of sequence pins
[04:00:55] <SWPLinux> it allows for crewups between config tool, driver, and FPGA revisions as well
[04:00:57] <SWPLinux> screwups
[04:01:03] <jmkasunich> yep, forget I said that
[04:01:32] <SWPLinux> actually, it can still work, but you need the instance number
[04:01:53] <jmkasunich> might need both
[04:02:08] <SWPLinux> but I think I agree that you only need either the pin number or the instance number (in most situations anyway)
[04:02:27] <jmkasunich> most is the killer - it only takes one case to bust it
[04:02:30] <SWPLinux> heh
[04:02:54] <jmkasunich> I keep thinking of the 5i22 coming, with 96 pins
[04:03:09] <jmkasunich> if we went to 512x32, then you have 128 words per ribbon cable
[04:03:30] <jmkasunich> 5 and a third words per pin
[04:03:50] <SWPLinux> that ought to be plenty, I think
[04:04:46] <jmkasunich> 16 bits per possibility, 4 instance, 4 pintype, 8 object type (or some other mix, maybe 5, 5, 6)
[04:04:53] <jmkasunich> 8 choices = 4 words
[04:05:15] <jmkasunich> leaves 1-1/3 words for the "chosen" info
[04:05:27] <SWPLinux> is the FPGA ID supposed to be in the same memory space?
[04:05:37] <jmkasunich> yes
[04:05:41] <SWPLinux> ok
[04:05:45] <jmkasunich> there will need to be a few spare words at the end of the ram
[04:05:53] <jmkasunich> I'm thinking an ID code and a checksum
[04:06:42] <SWPLinux> I'd use only one word for "chosen" then, 3 bits for the mux, a couple others for export/no export input pin, a couple of others for invert / tristate / open collector / pull-up/pull-down ...
[04:06:51] <jmkasunich> if I wasn't worried about using up address space, I'd say switch to 16 bit wide ram
[04:06:55] <SWPLinux> the ID should be at the beginning
[04:07:07] <SWPLinux> since the RAM size may be dependent on the config
[04:07:16] <jmkasunich> I guess
[04:07:25] <jmkasunich> that mucks with addressing though
[04:07:33] <jmkasunich> everything becomes N+1
[04:07:55] <jmkasunich> I guess if you overlay a struct on it its a non-issue though
[04:07:55] <SWPLinux> no, the base address just starts out a little higher ...
[04:08:02] <jmkasunich> right
[04:08:23] <jmkasunich> about the x16 thing...
[04:08:35] <jmkasunich> if we did that, we'de have one RAM block per connector
[04:08:41] <jmkasunich> 3 on the 5i20, 4 on the 5i22
[04:09:10] <jmkasunich> and each block would start with 24*8 16 bits "possibiltiies" (after the id code)
[04:09:47] <jmkasunich> followed by 24 16 bits words containing 3 bit choice plus the other misc bits
[04:10:26] <jmkasunich> dunno if it makes much of a difference really
[04:10:44] <jmkasunich> (compared to always having 4 blocks and packing the 16 bit codes 2 per word)
[04:10:48] <SWPLinux> nope - I think that stuff gets read/written once per run
[04:10:58] <jmkasunich> I wasn't thinking speed
[04:11:12] <jmkasunich> more just code cleanness, etc
[04:11:14] <SWPLinux> yep
[04:11:29] <jmkasunich> if each connector is treated individually, the change from 5i20 to 5i22 is smoother
[04:11:39] <SWPLinux> I'd make the header block contain other info as well:
[04:11:44] <jmkasunich> right
[04:11:58] <SWPLinux> we already have FPGA ID code
[04:11:59] <jmkasunich> like a version code that lets us change the protocol later if we realize we borked it up
[04:12:02] <SWPLinux> yes
[04:12:11] <SWPLinux> also change the pin data format
[04:12:46] <SWPLinux> and possibly the data space per "function" (ie, does a stepgen take 4 dwords or 8 ...)
[04:12:46] <jmkasunich> more bits for one field, less for another
[04:12:51] <SWPLinux> right
[04:13:04] <jmkasunich> I don't follow that last one
[04:13:21] <jmkasunich> we seem to be taking the per pin approach, so it doesn't matter how many a stepgen takes
[04:13:25] <SWPLinux> ideally, the number of bits per field would be directly encoded, but a "version number" is also useful
[04:13:40] <SWPLinux> I'm talking about actually addressing them inthe driver, not just the pin functions
[04:14:08] <jmkasunich> oh, you mean the registers that the driver needs to access?
[04:14:10] <SWPLinux> consider that the driver may want to work with multiple versions of the FPGA code
[04:14:11] <SWPLinux> ys
[04:14:11] <SWPLinux> yes
[04:14:16] <jmkasunich> the numver of those is the least of the drivers worries
[04:14:39] <jmkasunich> I'd be more inclined to have a version code for each thing type to deal with that
[04:14:59] <SWPLinux> yeah - I guess tables can be in the driver much easier than in the FPGA
[04:15:02] <jmkasunich> "ok, this is a rev 2 stepgen, it doesn't have a foo register, and the bar register is signed, not unsigned"
[04:15:43] <SWPLinux> yep - worst case is that the "update" functions are completely separate and the driver only exports the correct one as a hal funct
[04:15:51] <jmkasunich> right
[04:16:06] <jmkasunich> actually, I was just thinking about a "rev2 stepgen" being a differnt "thing" code
[04:16:20] <SWPLinux> hmmm
[04:16:31] <jmkasunich> 3 is the original stepgen, 4 is the original pwmgen, and 26 is some much later stepgen
[04:16:34] <SWPLinux> I think that would be a bad idea, but I also think it may be a good idea ...
[04:16:42] <jmkasunich> same here
[04:16:48] <jmkasunich> it could eat up thing codes
[04:16:54] <SWPLinux> yes
[04:17:01] <jmkasunich> but it eliminates a whole list of "thing versions"
[04:17:12] <SWPLinux> actually, a single FPGA is likely to have only one revision of stepgen, no?
[04:17:18] <jmkasunich> right
[04:17:34] <SWPLinux> then I'd have a single list of thing revisions for the whole FPGA
[04:17:42] <SWPLinux> and thing types per pin can be short
[04:17:46] <jmkasunich> right, that was understood
[04:18:03] <jmkasunich> but if there are 10 possible things, that means 10 thing revs in the master header
[04:18:14] <jmkasunich> or 16, or 32, or whatever
[04:18:32] <SWPLinux> it's bounded by the number of bits in the pin-thing field
[04:18:40] <jmkasunich> if we have 8 bits for "thing-code" then we'd need 256 versions
[04:18:58] <SWPLinux> yep
[04:19:00] <jmkasunich> or we could store "thing_code/version" pairs, for only those things in this fpga
[04:19:28] <jmkasunich> actually, that could do a lot of compression
[04:19:46] <SWPLinux> yeah - even if there are 100 possible things to put in the FPGA, how many will realistically be available in one config?
[04:19:59] <jmkasunich> if a single FPGA never has more than 16 differnt kind of things in it, you can have an array that says "thing code 3 is a version 12 stepgen"
[04:20:12] <SWPLinux> ah - right
[04:20:33] <jmkasunich> thing codes can be 4 bits, but the thing type can be 8 bits for type and 8 more for version
[04:20:45] <jmkasunich> the table would be 16 words of 16 bits
[04:20:48] <SWPLinux> yep, and you only need 16 of those
[04:21:10] <jmkasunich> not sure about 16 though
[04:21:21] <jmkasunich> again, it depends on how you deal with things like step-type
[04:21:25] <SWPLinux> 16 is a lot for one config
[04:21:39] <jmkasunich> you might have "stepgens" in the fpga, but its capable of doing 12 step types
[04:22:12] <jmkasunich> if "stepgen" is a thing, then its pins are step, dir. up, down, A, B, C, D, E
[04:22:16] <SWPLinux> yeah - there are pin configs and there are also function configs
[04:22:23] <SWPLinux> such as "base clock selection"
[04:22:23] <jmkasunich> if "step/dir stepgen: is a thing, it has fewer pins, but more types
[04:22:35] <SWPLinux> actually, that's a global config option
[04:22:48] <SWPLinux> then there are per type configs, then per instance configs
[04:22:57] <jmkasunich> remember anything that doesn't relate to exporting HAL pins/params can be done later (by setting the values of params)
[04:23:25] <jmkasunich> yeah, we've been overlooking the cross-connections
[04:23:42] <jmkasunich> I wonder
[04:24:12] <jmkasunich> with software stepgen, we decide step-type at insmod time, because we export HAL pins for step or up or phaseA
[04:24:32] <jmkasunich> with hw stepping, the hal pins are (almost) the same for all stepgens
[04:24:45] <jmkasunich> only the dirsetup/dirhold params differ
[04:25:12] <SWPLinux> but you don't know how many there are (configured or chosen ...)
[04:25:27] <jmkasunich> you know, the more I think about this, the more sense your original "do it by function, not by hardware pin" plan makes sense
[04:25:40] <SWPLinux> is it an error to not specify the step type for a stepgen, or is there a default (like type 0) ...
[04:25:49] <jmkasunich> on the sw one?
[04:26:00] <SWPLinux> no - I'm thinking of the FPGA version
[04:26:06] <jmkasunich> we haven't decided yet
[04:26:29] <jmkasunich> on the sw one, specing a type is how you say "I want to use this channel"
[04:26:38] <jmkasunich> the default types are -1
[04:26:41] <SWPLinux> actually, that's right. we don't care about pins because the connections are explicit in the FPGA
[04:27:05] <SWPLinux> the stepgen only has velocity or position to deal with
[04:27:16] <SWPLinux> (plus params as you mentioned)
[04:27:45] <jmkasunich> yeah, but we do somehow have to set a pin mux or something to send either "step" or "up" or "A" to the hardware pin
[04:28:09] <SWPLinux> that should be a config utility option
[04:28:16] <jmkasunich> right
[04:29:06] <jmkasunich> step types 0, 1, or 2+ is also a config option (because it affects the timing params that are exported), as is position/velocity
[04:29:12] <SWPLinux> ok. I'd like to think about this a bit more. I'm considering some sort of semi-hierarchical config, and I'm not sure I like it :)
[04:29:13] <jmkasunich> both of those things are on a per-instance basis
[04:33:47] <jmkasunich> I'm taking notes - I don't want to solve this and then forget it...
[04:34:02] <jmkasunich> so far, the "everything on a per-pin basis" idea is documented
[04:34:08] <SWPLinux> good idea
[04:34:13] <jmkasunich> but we've found holes in it
[04:34:41] <SWPLinux> I'm getting tired (strangely enough), and I've still got stuff to do tonight
[04:34:54] <jmkasunich> its 12:30 here too
[04:35:04] <jmkasunich> although I want to ponder "per thing" a little
[04:35:26] <SWPLinux> yep - only 9:30 here, but my body clock seems to be on the east coast still
[04:36:19] <jmkasunich> thing code; pin number for step/up/A ; pin number for dir/down/B ; pin number for C
[04:36:29] <jmkasunich> that defines a thing
[04:36:36] <jmkasunich> then you just turn it on
[04:36:45] <jmkasunich> (and turn off any conflicting things)
[04:37:04] <SWPLinux> it seems that groups of things that have different numbers of pins (say a stepgen overlaid with an encoder+index) needs some more complex construct
[04:37:18] <jmkasunich> yeah
[04:37:26] <SWPLinux> since the stepgen could have an input or an output (for example) on the extra pin
[04:38:00] <jmkasunich> I don't think in terms of stepgen overlaid on encoder
[04:38:04] <SWPLinux> so I'm trying to think through something that might work for the user. I think we have a reasonable idea of what to put in the FPGA (per pin anyway)
[04:38:15] <SWPLinux> ok, stepges type 1 + stepgen type 15
[04:38:30] <SWPLinux> both outputs, different number of pisn
[04:38:32] <SWPLinux> pins
[04:38:36] <jmkasunich> I think of "stepgen on pins 1, 2", encoder on pins 1, 2, 3, another stepgen on pins 3, 4 (or another stepgen on pins 4, 5)
[04:39:09] <SWPLinux> that's an FPGA near-impossibility, I think
[04:39:15] <jmkasunich> perhaps "if number of pins changes, its not the same thing anymore"
[04:39:42] <jmkasunich> the impossiblity thing - that was me not communicationg well
[04:39:59] <jmkasunich> the FPGA designer would pick the pins that are associated with each stepgen, encoder, etc
[04:40:05] <jmkasunich> they would not be configurable
[04:40:18] <SWPLinux> I think the pins will be broken into blocks, based on the largest function first, then the next largest, etc.
[04:40:34] <jmkasunich> my point was that an encoder doesn't neccessarily start (or stop) at the same pin as a stepgen
[04:40:38] <SWPLinux> sure
[04:40:38] <jmkasunich> they are completely independent
[04:41:05] <jmkasunich> blocks has issues
[04:41:17] <SWPLinux> look at is like overlapping windows. the largest function determines the window size, and no function should be in more than one window
[04:41:39] <jmkasunich> the largest function also determines the number of wasted pins, which can be large
[04:42:15] <SWPLinux> so a 6-ouput up/down 3-phase PWM would give us a 6-pin window size, and a 2-pin PWMgen should fit within a single window only - not cross the boundary between two 3-ph PWMs
[04:42:28] <SWPLinux> they're not wasted, they just need to be I/O
[04:42:39] <jmkasunich> I want to be able to do a FPGA that has pwmgens and encoders positioned to match up with a 7i33 board, and ALSO has stepgens on the same connector, with a completely different pinout
[04:42:55] <SWPLinux> night
[04:42:55] <SWPLinux> ;)
[04:43:12] <jmkasunich> I don't see why the location or size of an encoder would affect a stepgen
[04:43:16] <jmkasunich> goodnight
[04:43:19] <SWPLinux> heh
[04:43:47] <jmkasunich> blocks might be a way to compress data (by eliminating some arbitrary choices)
[04:43:47] <SWPLinux> I think the 7i33 has pins kind of scattered a little (not looking at the manual at the moment)
[04:43:54] <jmkasunich> yeah, it does
[04:44:12] <SWPLinux> sorry - I've been thinking of the user tool for a while, not the FPGA representation
[04:44:22] <jmkasunich> thats kind of why I like the idea of storing "instance, pinnum, pinnum, pinnum"
[04:45:19] <jmkasunich> I should list all these various cases so for reference
[04:45:36] <jmkasunich> stepgens of differnet types, and what that means both in hardware terms and for the driver
[04:45:41] <jmkasunich> (for example)
[04:45:50] <SWPLinux> ok, so "unselected" would be an option everywhere, but I'm not sure how I'd organize the function selectors
[04:46:12] <jmkasunich> to be honest I have no idea how I'd do all the steptypes - a 14 wide mux would be a killer
[04:46:26] <SWPLinux> yeah - I guess a listing of what the existing Mesa peripheral cards are would be a good start
[04:46:31] <SWPLinux> heh
[04:47:08] <jmkasunich> peter mentioned something about each lut being usable as a 16x1 ram
[04:47:17] <SWPLinux> I'd split it onto several sets of stepgen types (even though they're mostly the same)
[04:47:29] <jmkasunich> 5 of them could be a state table for types 2-5
[04:47:40] <SWPLinux> 1) types that are meant to control a motor driver
[04:47:46] <jmkasunich> if the hal driver could somehow load the appropriate pattern into them
[04:47:53] <SWPLinux> 2) types that are meant to directly energize coils
[04:47:59] <SWPLinux> 3) 5-phase
[04:48:13] <jmkasunich> 5 phase is also meant to directly energise coils
[04:48:32] <SWPLinux> yeah, but I think it's way less common than 2/4-phase
[04:48:49] <SWPLinux> it's also an odd number of pins, and therefore a PITA :)
[04:49:19] <jmkasunich> are you saying they'd be different at the VHDL level, and 5-phase people would build a unique bitfile?
[04:49:49] <SWPLinux> I'd say that there's not much need for 5-phase waveforms in the "stock" bitfile
[04:50:01] <jmkasunich> probably very true
[04:50:12] <jmkasunich> until this evening I was planning for types 0, 1, and 2 only
[04:50:21] <jmkasunich> step/dir, up/down, and quad
[04:50:29] <SWPLinux> I can agree with that, at least for now
[04:50:51] <jmkasunich> but the other types are a very good test case for evaulating some of these concepts
[04:50:54] <SWPLinux> maybe - just maybe - the direct-drive 4-coil ones as well, but only a very big maybe
[04:52:24] <jmkasunich> it would simplify things if a "thing" always had the same number of pins
[04:53:09] <SWPLinux> yeah
[04:53:45] <SWPLinux> that was the idea with the 6-pin blocks
[04:54:00] <jmkasunich> if the ram was treated as a variable length stream instead of a block...
[04:54:06] <SWPLinux> (6 because you get 4 per connector that way)
[04:54:24] <jmkasunich> thing-code, pin-num, pin-num, pin-num, thing-code, pin-num, thing-code, pin-num, etc
[04:54:50] <jmkasunich> thing instances would be assigned sequentially whenever you encounter a thing code
[04:54:54] <SWPLinux> pin-num = what? the index of the pin name for that function?
[04:55:32] <jmkasunich> example: stepgen, 23, 30, pwmgen, 24, 31
[04:55:39] <SWPLinux> ah
[04:55:55] <jmkasunich> that means stepgen.0.step is on pin 23, stepgen.0.dir is on pin 30
[04:56:10] <SWPLinux> ok, so any number with the high bit set is a thing type, and below that is a pin number
[04:56:18] <jmkasunich> yeah
[04:56:32] <jmkasunich> although if each thing has a known number of pins, even that code isn't needed
[04:56:53] <jmkasunich> either way, the util can read that and prepare the "72 menus" from it
[04:57:06] <jmkasunich> not sure the 72 menus is the way to go, but the data is all there
[04:57:10] <SWPLinux> might as well use bytes - it's easier
[04:57:25] <SWPLinux> you need 7 bits per pin anyway
[04:57:27] <jmkasunich> right
[04:57:47] <jmkasunich> the high bit code limits you to 128 things instead of 256, but thats not a big thing
[04:58:10] <SWPLinux> 127: "end of list" is a thing as well :)
[04:58:26] <jmkasunich> heh, you could even follow the first instance of a new thing code with a thing version, before you start the pin numbers
[04:58:32] <SWPLinux> unless you have an explicit count of all things in the fpga
[04:58:37] <jmkasunich> that way you only store versions for stuff you have in the fpga
[04:58:59] <jmkasunich> I agree that an end code is a good thing
[05:00:35] <SWPLinux> how about "thing type, numpins, pin, pin, pin ..."
[05:00:48] <jmkasunich> details
[05:01:29] <jmkasunich> the basic idea is "stream instead of fixed addressing"
[05:01:39] <SWPLinux> stepgen1, 2, 23, 34, 24, 35, 25, 36 gives 3 stepgens, on pins (23,35), (24,36) and (25,36)
[05:01:42] <SWPLinux> sure
[05:01:43] <jmkasunich> and "thing vs pin" based
[05:02:24] <jmkasunich> why not stepgen 23 34 stepgen 24 25 stepgen 25 36?
[05:02:42] <SWPLinux> takes too much space ;)
[05:02:42] <jmkasunich> when you encounter "stepgen", you increment the instance number
[05:02:58] <jmkasunich> stepgen is a code, not a string
[05:03:43] <SWPLinux> I understand that - the representation I had encoded the number of pins per instance so that the pins would implicitly define how many instances there are
[05:03:58] <SWPLinux> without the util or driver needing to know that for every thing type
[05:04:20] <SWPLinux> though I guess they need to know anyway, at some level
[05:04:36] <jmkasunich> yeah... I was thinking that you might have "stepgen, 1, 2, pwmgen 3, 4, stepgen, 5, 6" but you'd never need to switch back and forth like that
[05:04:57] <jmkasunich> and if you aren't switching, then you might as well not repeat the type
[05:05:04] <SWPLinux> right
[05:05:27] <jmkasunich> you'd definitely follow the type with a version code
[05:05:30] <jmkasunich> and maybe even with a subtype
[05:05:50] <SWPLinux> so if the utility and driver know how many pins each thing takes, the number of things is well-defined
[05:05:50] <jmkasunich> (for things like stepping type)
[05:06:08] <SWPLinux> if you put in a quantity field, then you can do shorthand as well
[05:06:37] <SWPLinux> such as stepgen, 3(qty),1 -> 3 stepgens, using as many pins as needed starting at 1
[05:06:52] <jmkasunich> I don't see a need to go that far
[05:07:02] <SWPLinux> you only need to specify the pins if they're non-contiguous
[05:07:07] <jmkasunich> the size of the ram is dictated by the least compressible combination, not the most compressible one
[05:07:17] <jmkasunich> why make the code more complex
[05:07:55] <jmkasunich> (we know the 7i3x boards use non-contiguous pins, so we know we're gonna have some rather non-compressible configs
[05:08:23] <jmkasunich> our prior version was 12 to 16 bits for each of 8 possibilities
[05:08:33] <SWPLinux> hmmm. this doesn't tell us which function of the pin (mux-wise) is which
[05:08:54] <jmkasunich> this one is 8 to 12 bits per possibility, only for the ones that exist
[05:08:58] <jmkasunich> I don't follow?
[05:09:06] <SWPLinux> we may have 3 things on one pin, but we haven't said which mux option gives us whhat function
[05:09:18] <jmkasunich> ah
[05:09:30] <jmkasunich> maybe we don't use muxes
[05:10:00] <SWPLinux> I guess the function enables can semi-automatically select the pin function
[05:10:07] <jmkasunich> if we are enableing and disabing on a per-thing basis, we arrange for all disabled things to output zero, and use a big OR gate instead of a mux
[05:10:14] <SWPLinux> even if they are muxes
[05:10:18] <SWPLinux> right
[05:10:42] <jmkasunich> big or gates might be nicer than muxes anyway
[05:11:38] <jmkasunich> maybe the 72 menus aren't menus - they're just lists
[05:11:42] <SWPLinux> should be one LUT per 4 bits, no selectors needed
[05:11:48] <SWPLinux> drop-downs
[05:12:01] <jmkasunich> showing the one currently enabled thing that drives that pin
[05:12:29] <SWPLinux> there's a problem with graying out other things once you've selected some things
[05:12:32] <jmkasunich> if you enable stepgen.0, that sets pins 23 and 34 to stepgen.0.step and stepgen.0.dir
[05:13:24] <SWPLinux> that would be useful for documentation purposes - ie, if it can print (or PDF) a pinout
[05:13:29] <jmkasunich> yeah
[05:13:53] <SWPLinux> ok - I do need to hit the sack now. I think we may have gotten somewhere though
[05:14:04] <jmkasunich> the util will be able to do that, regardless of how it works
[05:14:07] <jmkasunich> yes, thanks much
[05:14:20] <SWPLinux> my pleasure - this is the fun stuff :)
[05:14:29] <SWPLinux> at least, some of it
[05:14:38] <SWPLinux> good night
[06:27:26] <jepler> I notice cradek's gone on an axis development spree since I left town
[06:29:58] <alex_joni> 03:21 < cradek> I'm thinking of crapping up axis some more while jepler's gone
[06:30:03] <alex_joni> 03:22 < jmkasunich> ;-)
[06:30:05] <alex_joni> 03:22 < jmkasunich> go for it
[06:30:06] <alex_joni> 03:22 < jmkasunich> he can only kill you once
[06:30:07] <alex_joni> jepler: :P
[06:33:21] <jepler> hah
[06:33:24] <jepler> I figured it was something like that
[06:37:33] <jepler> time to go catch a train
[06:37:35] <jepler> cradek: knock yourself out
[17:28:50] <SWPadnos__> SWPadnos__ is now known as SWPadnos