#emc-devel | Logs for 2007-05-18

[00:20:36] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[01:05:37] <jmkasunich> dang... I think I need 9 bits to configure a GPIO pin
[01:06:22] <petev> why so many?
[01:06:28] <jmkasunich> http://pastebin.ca/493979
[01:06:40] <jmkasunich> to tell the driver how to present the pin to HAL
[01:07:28] <petev> why do you need to not export the invert params?
[01:07:32] <jmkasunich> I'm trying to allow both a general config (pin controlled by hal pins/params) and a specific, less cluttered one (pin configured at driver load time, fewer HAL pins)
[01:08:05] <petev> why not just select the HW options and then export everything appropriate?
[01:08:17] <jmkasunich> ?
[01:08:33] <petev> maybe I'm missing something in the paste
[01:08:58] <petev> seems like some of it effects HW function and some is just export options
[01:09:43] <jmkasunich> actually everything there is controlled by the driver, the FPGA config is the same always
[01:10:07] <petev> yes, that I understand
[01:10:14] <petev> for example
[01:10:27] <petev> if the user just wants a totem pole output
[01:10:47] <petev> why not just specify that and export all appropriate pins/params?
[01:11:00] <petev> why all the separate export options?
[01:11:35] <jmkasunich> flexibility... what you are saying makes sense, although it would require a detailed listing of the options
[01:11:50] <jmkasunich> there are 512 combinations in that listing, not all of them make sense
[01:12:01] <jmkasunich> If I enumerated them, I might have less than 256
[01:12:02] <petev> you might be able to compress the selection to an input option and an output option
[01:12:06] <petev> then use a few bits each
[01:12:15] <petev> then maybe you can get it into 8-bits
[01:14:14] <jmkasunich> maybe
[01:14:26] <jmkasunich> I have a hunch its not gonna compress as much as I hope
[01:14:40] <jmkasunich> many of the bits in the initial pastebin are orthogonal
[01:14:55] <petev> let's list input and output options
[01:15:00] <jmkasunich> inverting and open collector, for example, would apply to all outputs
[01:15:14] <petev> for output you have off, totem, open-col, tri-state
[01:15:31] <jmkasunich> with and without inversion
[01:15:32] <petev> yes, and an invert bit for all
[01:15:51] <petev> what are the input options other than off, and on?
[01:15:51] <jmkasunich> tri-state gets messy, because then you have to decide where the OE is coming from
[01:16:06] <jmkasunich> inversion, maybe
[01:16:08] <petev> wouldn't you just export an OE pin for that?
[01:16:35] <petev> so 2-bits for input with inversion bit
[01:16:55] <petev> and 3 for output with inversion bit
[01:16:57] <jmkasunich> I'm thinking that someday (maybe sooner than later) there will be an FPGA (VHDL) block that does SPI or something else that needs to be able to tri-state under FPGA control, not HAL control
[01:16:59] <petev> that's only 5 total
[01:17:13] <petev> hmm
[01:17:37] <petev> how would that block get connected to the pins?
[01:17:45] <petev> this would happen through the driver config?
[01:17:50] <petev> like HAL within the FPGA?
[01:17:54] <jmkasunich> it would happen in VHDL
[01:18:16] <petev> if it's in VHDL, then why do you need config bits for it?
[01:18:22] <jmkasunich> there would be the VHDL block that does whatever, and the VHDL block that is a "pin driver" (containing all the GPIO registers and inversion logic and OC logic and such
[01:18:53] <petev> and you would be able to route the SPI block to any IO pins and configure them dynamically?
[01:18:55] <jmkasunich> the pin driver would have "internal output", "internal input" and "internal OE" ports that could be connected to something in the FPGA, or not
[01:19:03] <jmkasunich> no, not dynamic
[01:19:17] <petev> when then, at VHDL synth time?
[01:19:40] <jmkasunich> you'd decide in the top level VHDL that "pins 2, 3, and 4 are connected to SPI port 1"
[01:19:51] <petev> sure
[01:20:07] <jmkasunich> then the only option after place-n-route is to say "I'm not using SPI 1, let me use those pins as GPIO"
[01:20:16] <petev> but why isn't all that args to the comp instantiation in VHDL then?
[01:21:08] <petev> sounds like the SPI block would just take over IO control of the pin when it's enabled, and the GPIO would have control when not
[01:21:16] <jmkasunich> because most folks don't have the VHDL tools, or don't know VHDL, or both
[01:21:25] <petev> I don't follow
[01:21:31] <petev> you write the VHDL
[01:21:39] <petev> and you assign the SPI to some pins
[01:21:46] <petev> and the signals get connected
[01:21:57] <petev> and you have a flexible pin driver that takes some args
[01:22:13] <petev> maybe you tell it there are 2 control sources and it creates muxes or whatever
[01:22:26] <petev> then everything gets synthed and routed
[01:22:36] <petev> and the only user option is who controls the pin
[01:22:41] <petev> SPI, or GPIO
[01:23:03] <jmkasunich> the problem is that there are too many variations
[01:23:12] <jmkasunich> for SPI, what you are saying makes perfect sense
[01:23:17] <jmkasunich> for stepgen there are problems tho
[01:23:30] <petev> are you trying to provide routing flexibility at run time?
[01:23:38] <jmkasunich> not routing, just config
[01:23:38] <petev> where do the problems come in?
[01:23:57] <jmkasunich> for example, stepgen - if I'm driving geckos, I want an active low step pulse, and open collector output
[01:24:07] <jmkasunich> (since the FPGA can only drive up to 3.3V)
[01:24:44] <petev> ok, but stepgen would have to have control signals for the IO pin to use that
[01:24:47] <jmkasunich> so even tho stepben "controls" the pin, I still need to be able to acces the "OC" and "invert" capabilities of the GPIO pin driver
[01:25:08] <petev> oh, I think we are mixing things up a bit
[01:25:24] <petev> the GPIO block is what I was calling the user level IO block
[01:25:36] <petev> then you have your SPI and stepgen blocks
[01:25:49] <petev> and then some type of configurable IO block
[01:26:06] <petev> the IO block gets controlled by the SPI, stepgen, or GPIO
[01:26:08] <jmkasunich> ok, the config IO block would be what I'm calling the pin driver
[01:26:12] <petev> yes
[01:27:17] <jmkasunich> so the pin driver would have bits (or hal params) for off, on (totempole), OC and tristate
[01:27:20] <petev> so the IO block probably exports are IO cell control pins and maybe instantiates muxes and select lines as well for IO pin sharing
[01:28:01] <petev> I don't think the pin driver would ever be exported directly as HAL pins/params, although the GPIO block may look very similar to it
[01:28:26] <petev> ^are IO^all IO^
[01:28:26] <jmkasunich> I was thinking of the pin driver and GPIO block as one and the same... splitting them might have some advantages
[01:28:35] <petev> right
[01:29:21] <jmkasunich> another thing I was trying to allow is letting you export a HAL input pin for a physical pin that is either an input to or an output from some internal thing (stepgen, encoder, SPI, etc)
[01:29:38] <jmkasunich> that would let you use scope or meter for testing (within their respective bandwidth limits)
[01:30:05] <jmkasunich> IOW, see what your stepgen is putting out, or see what is coming from your encoder and going to the FPGA encoder counter
[01:30:14] <petev> maybe build some type of crossbar for that and have all the internal pins go to it too
[01:30:24] <jmkasunich> heh
[01:30:27] <petev> the ADI DSPs have a configurable IO crossbar
[01:30:43] <petev> it allows 20 external pins to be routed to any of the internal function blocks
[01:30:49] <jmkasunich> I'm having this conversation in an attempt to find a simpler solution to my problems, not make them harder
[01:31:00] <petev> and there is another one that routes internal connections between blocks
[01:31:02] <jmkasunich> that would get expensive on the 5i20
[01:31:09] <jmkasunich> wide muxes are very expensive
[01:31:15] <petev> yeah, but you're trying to do a lot
[01:31:44] <petev> if you want it simple, maybe have a coulple of muxes on diag pins and call it a day
[01:31:53] <jmkasunich> I'm content for each pin to be either a single specific function (step, dir, spi-data, spi-clock, encoder-phase-a, etc) or GPIO
[01:31:58] <petev> then you can select 2 or so signals to look at
[01:32:25] <petev> the other option, although not preferred, is to use tristate inside the FPGA
[01:32:38] <petev> not sure if the xilinx part supports it, but most do
[01:33:07] <jmkasunich> the hardware for reading any hardware pin as a HAL input is gonna be there regardless, so allowing any pin to be exported as an input is a cheap and easy way to get diagnostics
[01:33:15] <jmkasunich> I don't want to take the diag thing any farther than that
[01:33:50] <petev> Oh, I thought you were saying you might want to route some internal signal to a pin so it could be viewed?
[01:33:59] <jmkasunich> sorry, I wasn't clear
[01:34:09] <jmkasunich> when I said scope and meter, I meant halscope and halmeter
[01:34:12] <petev> so I was thinking only put that capability on a few of the pins, not all of them
[01:34:22] <jmkasunich> if you have a physical scope, you can already access all the 72 pins
[01:34:38] <petev> right, but what about internal signals, or do you not need that?
[01:35:01] <jmkasunich> I wasn't thinking of that - a VHDL developer might want something like that, but users won't
[01:35:20] <petev> the VHDL developer will most likely be happy with the simulation
[01:35:30] <jmkasunich> users will say "why ain't my fscking encoder counting" and a logical first step is to see if there is something arriving at the input pins
[01:35:38] <petev> I was thinking there might be some internal sigs that would be usefull for user level diag
[01:35:49] <petev> but I don't know what you have in there so it's just speculation
[01:36:18] <jmkasunich> that would vary on a module by module basis - stepgen might have some that encoder won't, etc
[01:36:28] <petev> crap, I'm supposed to be on a call
[01:36:28] <jmkasunich> and they can be exported to HAL by the stepgen-specific driver code
[01:36:30] <petev> bbiab
[01:36:32] <jmkasunich> oops
[04:27:13] <jmkasunich> petev: http://pastebin.ca/494277
[04:27:15] <jmkasunich> more thoughts
[04:27:39] <jmkasunich> I'm going to bed... would be nice to discuss this some tomorrow - it really helps to be able to talk things thru
[04:27:52] <petev> ok, I'll take a look
[04:28:04] <jmkasunich> didn't realize you were back
[04:28:16] <petev> just got the kids to bed, almost ;-)
[04:35:50] <petev> u still up?
[04:35:55] <jmkasunich> yeah
[04:36:08] <petev> how will the internal functions be enabled/disabled?
[04:36:20] <petev> stuff like SPI, stepgen, etc.
[04:36:31] <jmkasunich> stepgen is the only one I have working now
[04:36:46] <petev> but it is an option for it to be disabled?
[04:36:48] <jmkasunich> it has a 2 bit mode register: off, step/dir, up/down, and quadrature
[04:36:55] <petev> ok
[04:37:17] <petev> I think I would lean towards having an internal function take over control, rather than oring it with GPIO
[04:37:19] <jmkasunich> there are a few bytes in the config ram that say "enable (and export the hal pins for) stepgen N"
[04:37:37] <jmkasunich> a proper mux instead of an OR gate
[04:37:43] <petev> I think it will save much debug headache, and probably won't cost anything in terms of xilinx gates
[04:37:45] <petev> yes
[04:37:52] <jmkasunich> I agree, but that means more bits of config info, not less
[04:38:09] <petev> I think the xilinx blocks will do a mux with the same resource usage
[04:38:25] <petev> why, you already have the mode bits for stepgen
[04:38:28] <petev> they would control the mux
[04:38:47] <jmkasunich> oh, I see what you are getting at
[04:38:47] <petev> so when stepgen is enabled, it controls the IO pins
[04:39:14] <jmkasunich> the reason I wasn't thinking that way is that the stepgen is a self contained block with just two output pins
[04:39:14] <petev> so if no internal function is using the pins, then the gpio function gets them by default
[04:39:26] <jmkasunich> I could certainly add a third that says "I'm enabled"
[04:39:48] <petev> right, it's internal, and I'm sure there are enough internal routing resources
[04:40:50] <jmkasunich> in a way, there is already half a mux in the stepgen
[04:40:54] <petev> if you don't take the simple approach of export everything, is the config for the IO going to be put in the 1K of data?
[04:40:59] <jmkasunich> when disabled, its outputs are forced to zero
[04:41:08] <jmkasunich> yes
[04:41:23] <petev> and how does the user set that data, is there some tool?
[04:41:30] <jmkasunich> yeah
[04:41:46] <jmkasunich> there is a simple file format, like so:
[04:41:51] <petev> how does the tool know what the options are? Is it specific to the driver?
[04:42:03] <jmkasunich> its not that fancy a tool (yet)
[04:42:04] <jmkasunich> # specify the bitfile:
[04:42:04] <jmkasunich> ## use size.bit
[04:42:04] <jmkasunich> @4
[04:42:04] <jmkasunich> # protocol version
[04:42:04] <jmkasunich> 1
[04:42:06] <jmkasunich> # board type code
[04:42:07] <jmkasunich> 1
[04:42:10] <jmkasunich> # stepgens have 5 byte blocks
[04:42:12] <jmkasunich> # byte 0: block type, 10/11 = vel mode or position mode
[04:42:14] <jmkasunich> # bytes 1-2: base address (in the FPGA)
[04:42:16] <jmkasunich> # byte 3: pin number for step/up/phaseA
[04:42:18] <jmkasunich> # byte 4: pin number for dir/down/phaseB
[04:42:20] <jmkasunich> 10 w0x400 0 1
[04:42:21] <jmkasunich> 10 w0x410 2 3
[04:42:49] <jmkasunich> that file says "start at address 4, store 1, 1, 10, 0x400, 0, 1, 10, 0x410, 2, 3"
[04:43:23] <petev> so the tool parses some info from the bit file?
[04:43:29] <jmkasunich> there would be more of the same for the rest of the stepgens, then the as yet undefined codes for GPIO config, etc, etc
[04:43:54] <jmkasunich> the tool doesn't parse anything
[04:44:12] <jmkasunich> the user writes (or more likely modifies) the file format above, with ye olde text editor
[04:44:34] <petev> so who reads this file?
[04:44:36] <jmkasunich> the "tools" are just used to merge that file with the bitfile and get it loaded into the FPGAs ram
[04:45:02] <petev> but the tool puts it into a binary form with the merge?
[04:45:17] <jmkasunich> the xilinx format breaks the bitfile into chunks - they use 5, 4 have info about the file, the 5th has the bitstream... I just added a 6th for the config ram data
[04:45:42] <jmkasunich> and my version of the loader loads the bitstream first, then reads the 6th chunk and writes that into the FPGA's ram
[04:45:45] <petev> but what's the format of the config ram data? it's not ascii is it?
[04:46:02] <jmkasunich> my config ram data? the 1K? its binary
[04:46:36] <petev> right, so there is some grammar the tool understands and the usre write, then the tool converts it to binary and merges it with the rest of the FPGA config?
[04:46:53] <jmkasunich> yeah
[04:47:15] <petev> so the user really needs to know the low level register bits as that's what the current language looks like?
[04:48:12] <jmkasunich> yeah, at this point they have to know that "10" is the code for a vel mode stepgen, and that the next two bytes are the HW address of that stepgen (determined in the VHDL), and that the VHDL connects it to pins 2 and 3
[04:48:24] <petev> ok
[04:48:46] <petev> I'm still struggling a bit with the separation of the FPGA implementation and the HAL view of it
[04:48:47] <jmkasunich> however, the most common thing they'd do with a stepgen line is comment it out, which results in the driver not exporting any stepgen stuff and the stepgen remaining disabled
[04:48:53] <jmkasunich> so its not too painfull
[04:48:54] <petev> I think they are still a bit too merged
[04:49:22] <petev> it seems like at the low level you want to config the HW/FPGA
[04:49:32] <petev> then on top of that you want a HAL view of the HW
[04:49:36] <jmkasunich> right
[04:50:03] <petev> you may be able to determine the HAL view from the config, but most likely it will not be ideal
[04:50:21] <petev> so you really want a second layer of config info for the driver HAL exports
[04:50:25] <jmkasunich> well, the goal is to define the config such that I can determine it
[04:50:37] <jmkasunich> "config" in this case means that 1K ram block
[04:51:03] <petev> but the register bits that are optimal for the FPGA implementation, may not be so hot for specifying the HAL view
[04:51:16] <petev> yes, so maybe that block is two parts
[04:51:27] <petev> one for FPGA register values, and one for HAL view
[04:51:37] <jmkasunich> not sure I follow you
[04:51:59] <jmkasunich> the config ram simply tells the hal driver "there is a stepgen at FPGA address 0x400"
[04:52:13] <jmkasunich> there is stepgen specific code in the driver that knows what that means
[04:52:19] <petev> if the FPGA register values map pretty well to the internal signals needed to control the IO cells, that may not be a good specification for the HAL view
[04:52:32] <petev> for instance, the user may not want the input pins/params
[04:52:39] <jmkasunich> in this case, three writeable regs and one readable one, with rate, three time values, mode, and enable, packed into them
[04:52:40] <petev> but you won't have any way to know that
[04:53:22] <jmkasunich> that kind of thing is exactly the issue that I've been talking about all evening
[04:53:28] <petev> I understand that, I was focusing more on the gpio HAL view
[04:53:58] <petev> so at the low level there is some reg init data that sets up the FPGA
[04:54:30] <petev> then I think some higher level HAL config data might be appropriate to avoid the name space polution you are concerned with
[04:54:31] <jmkasunich> I want to stick a couple bytes in the 1K block that let the user say "for I/O pin 26, I want a HAL input pin so I can see what is going on, I want the pin to be driven by the stepgen, and I want it active low, open collector"
[04:55:15] <petev> do you want the user to see the HW/HAL separation or you want to treat it as one from his point of view?
[04:55:21] <jmkasunich> "for I/O pin 31, I want a HAL output pin, and a HAL output-enable pin"
[04:55:35] <jmkasunich> I think you lost me again
[04:55:42] <jmkasunich> there is lots of HW/HAL separation
[04:56:02] <jmkasunich> for example, the HW will put 24 "output-enable" pins in a single register
[04:56:29] <petev> when the user writes the config file for the tool, do you want him to be aware of the separation of config data, or should the tool do it?
[04:56:32] <jmkasunich> there may only be HAL pins for a few of them, the others are static, defined by the config ram
[04:57:00] <jmkasunich> when he's writing the config file, he should be thinking in terms of "pin N should do this"
[04:57:13] <jmkasunich> and not care that in the HW, pin N is processed in parallel with 23 others
[04:57:19] <petev> right, so does the user specify the value for the reg, then the HAL view, or does he just specify what he wants for each pin and the tool builds reg values and HAL view?
[04:57:31] <jmkasunich> he specs what he wants for that pin
[04:57:45] <jmkasunich> my original 9 bit value was how I was gonna do that
[04:57:51] <jmkasunich> it would be something like:
[04:58:09] <jmkasunich> pin number, 9bitcode, another pin number, another 9bit code
[04:58:23] <petev> ok, so the tool will separate out the reg values and build them, so it won't be like the previouse example you gave of just specifying values to write to the register
[04:58:39] <jmkasunich> no, the tool just sticks the bytes in the fpga ram
[04:58:49] <jmkasunich> the driver reads them at insmod time and interprets them
[04:59:14] <jmkasunich> for a single GPIO connector (24 pins) there will be a series of 24 bit bitmasks in the driver
[04:59:30] <petev> ok, it may be simpler to let the tool do more work, then the driver can just load reg values and read some nice bit mask of HAL exports
[04:59:31] <jmkasunich> when the driver sees a code for pin 17, it will modify bit 17 of the various masks as needed
[05:00:06] <petev> why not push that work to the tool and simplify the driver?
[05:00:09] <jmkasunich> that means putting more knowledge in the tool and less in the driver
[05:00:15] <petev> yes
[05:00:17] <jmkasunich> and right now I'd rather have it all in one place
[05:00:32] <jmkasunich> (we've had this argument before, and I'm too sleepy to argue it again)
[05:00:44] <petev> it would make the driver simpler and save resources
[05:00:50] <jmkasunich> (we've had this argument before, and I'm too sleepy to argue it again)
[05:01:02] <petev> I'm just thinking you have limited 1K space and don't want to waste it being verbose
[05:01:08] <petev> I hear you
[05:01:29] <jmkasunich> I agree that I don't want to be verbose
[05:01:40] <jmkasunich> thats why I was bummed that I needed 9 bits
[05:02:01] <jmkasunich> I am forcing the user (at least right now) to work with bitfields, and the result is pretty darned compact
[05:02:10] <jmkasunich> a tool could simplify life for the user later
[05:02:12] <petev> if the tool did some processing, the 1K could be an array of reg init values, and a bit array of HAL exports
[05:02:21] <petev> but that would put more knowledge in the tool
[05:02:48] <jmkasunich> I initially started out thinking array (and smart tool)
[05:02:53] <jmkasunich> but that is really rather limiting
[05:03:06] <petev> if you want a higer level view for the user, I can make a quick parser for you so you don't need to deal with bit masks at the user level
[05:03:09] <jmkasunich> suppose I eventually wind up with 20 possible VHDL blocks
[05:03:34] <jmkasunich> stepgen, encoder, pwm, SPI, serial A/D, serial D/A, digital I/O expander, etc, etc
[05:03:59] <petev> either the user needs to know the details of each block, or the tool does
[05:04:18] <petev> so you just push the knowledge to the user if he has to figure out the bits
[05:04:36] <jmkasunich> I'm certainly open to nicer tools at the user level, but ultimately the data needs to be packed into something that is compact and documented
[05:04:43] <petev> how many FPGA configs do you plan on supporting?
[05:05:12] <petev> is it going to be just one config that gets morphed, or are you going to have multiple to optimize functionality?
[05:05:17] <jmkasunich> configs as in unique top-level VHDL, resulting in a unique mix of blocks that have been placed and routed?
[05:05:25] <petev> yes
[05:05:27] <jmkasunich> multiple
[05:05:42] <jmkasunich> a few that try to please 95% of the user base
[05:05:59] <jmkasunich> with the other 5% free to get the xilinx tools and build any combination they want
[05:06:32] <jmkasunich> I'm thinking the main "mainstream" one will be 8 PWM, 8 encoder, and 8 stepgen, mapped to pins such that you can use any or all of those functions
[05:06:40] <petev> so how does the tool know which config it's targeting, or does that knowledge get pushed to the user too?
[05:06:41] <jmkasunich> or turn off any/all and use the pins as GPIO
[05:07:07] <jmkasunich> there is a "## use foo.bit" line at the top of the file
[05:07:31] <petev> ok
[05:07:39] <jmkasunich> "use" means "merge this config ram info with that fpga bitstream"
[05:07:52] <petev> so does the tool do any error checking, or is that left to driver load time?
[05:07:59] <jmkasunich> driver load time
[05:08:07] <petev> hmm, not too user friendly there
[05:08:10] <jmkasunich> we need to use some words more precisely
[05:08:32] <petev> which words?
[05:08:54] <jmkasunich> I have two tools right now - the ".ram+.bit => .fpga" merge tool, and the ".fpga => 5i20card" loader
[05:09:11] <jmkasunich> there can also be a tool that is more user friendly and generates the .ram file
[05:09:24] <jmkasunich> that tool would do lots of checking
[05:09:38] <petev> ok, I think that would be good
[05:09:40] <jmkasunich> the merge tool is intentionally just a merger of binary data, it has no idea what the data means
[05:10:04] <petev> my first thought would be to have a generic tool that is driven by some descriptoin of valid options for a config and fully checks what the user has put in the file
[05:10:17] <petev> this is for the high level tool
[05:10:17] <jmkasunich> that would be nice
[05:10:26] <jmkasunich> I don't know how to write it though ;-)
[05:10:34] <petev> but that will distribute some of the knoledge, but I don't think that's bad
[05:10:42] <petev> I can help you with that
[05:10:47] <jmkasunich> with or without that tool, there has to be a format for the .ram file that the tool and the driver agree on
[05:10:54] <petev> yes
[05:11:07] <petev> why not make that as simple as possible to meet the needs?
[05:11:19] <jmkasunich> my goal for the moment is to establish that format, and have it not so obscure that you absolutly NEED the high level tool to write it
[05:11:25] <petev> where did you see the problems with the config data array approach?
[05:11:51] <petev> is that because you don't have the high level tool yet, or some other reason?
[05:12:02] <jmkasunich> if you're only dealing with the 8 stepgen/8 encoder/8 pwm/everything else GPIO case, arrays are fine
[05:12:42] <petev> where do you see it breaking down?
[05:12:48] <jmkasunich> if you want to allow a VHDL capable user to build a bitstream with 3 stepgens, 5 PWMs, 3 of another kind of PWM, 4 encoders, 2 DACs, 4 ADCs, etc, then it gets messy
[05:12:57] <jmkasunich> a stream handles that much better
[05:13:15] <petev> I'm not sure I see the problem
[05:13:38] <jmkasunich> the driver simply parses the stream - 1 byte says "this is a stepgen", the parser calls "export_stepgen", that reads the next byte or few, and exports whatever HAL stuff is needed for the stepgen
[05:13:38] <petev> wouldn't each of those modules have byte multiple registers that need writing with data?
[05:14:17] <petev> oh, I was still thinking along the lines of separate HW init data and HAL export data
[05:14:24] <petev> but I see where you're going
[05:14:25] <jmkasunich> each of those modules will have a "export" function in the driver, to export the relevant HAL pins and associate them with the relevant structure members in HAL memory
[05:14:49] <jmkasunich> each block will also have one or more RT functions, that do whatever is needed when you read or write to that block in RT
[05:15:11] <jmkasunich> for stepgen, it includes stuff like limiting velcoity anc accel, scaling, etc
[05:15:44] <petev> so you want to see more of a structured stream, and the driver will determine the HW config and appropriate HAL exports fomr it?
[05:15:53] <jmkasunich> yeah
[05:16:06] <petev> that could certainly work, but you might get more HAL namespace polution that you want
[05:16:16] <petev> but that may not be so bad
[05:16:23] <jmkasunich> just depends on how good the .ram protocol is
[05:16:31] <petev> maybe what's needed is more filtered views of HAL namespace ;-)
[05:16:42] <jmkasunich> yeah, no argument there
[05:16:50] <jmkasunich> but I'm not the guy to write that
[05:17:03] <petev> I don't think it would be that hard to make a parser that understands some basic syntax for this
[05:17:31] <petev> then the semantics could be read from some file that described each module and would be checked against it's rules
[05:17:52] <petev> if you have an idea for how you would like the language to look, I can make the parser pretty quickly
[05:18:31] <jmkasunich> I don't see how it can be that generic
[05:18:42] <jmkasunich> let me show you some of the structure I have now...
[05:18:43] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/hal_5i2x.c?annotate=1.3
[05:19:01] <jmkasunich> line 33 talks about the RAM content in general terms
[05:19:58] <jmkasunich> line 457-480 parses the stream
[05:20:14] <jmkasunich> there is a switch in there, that branches based on the first byte of each block
[05:20:20] <jmkasunich> "this block describes a stepgen"
[05:20:32] <petev> but this is inside the driver, it's not the high level user view
[05:20:33] <jmkasunich> "this block describes the GPIO options for a single pin"
[05:20:33] <jmkasunich> etc
[05:20:42] <petev> what does the user file look like at the high level?
[05:20:51] <petev> have you gotten to any examples of that yet?
[05:20:53] <jmkasunich> I pasted a sample a while ago
[05:21:09] <petev> that was pretty low level
[05:21:10] <jmkasunich> it was short, because all that config had was two stepgens
[05:21:19] <petev> it looked like write this data to this address
[05:21:40] <jmkasunich> the data is the stream
[05:22:08] <petev> I thought we were talking about making a higher level specification of the stream that was more user friendly?
[05:22:11] <jmkasunich> when the stream contains "10 0x0400 2 3" (in binary, 0A 04 00 02 03)
[05:22:23] <petev> yeah, but that's not user friendly
[05:22:34] <jmkasunich> that means "there is a stepgen at 0x0400 in the FPGA, and the user wants you to export the HAL pins to use it"
[05:22:57] <jmkasunich> friendly is the job of the next level tool
[05:23:00] <petev> wouldn't it be better to say something like stepgen = 0x400, etc.?
[05:23:18] <jmkasunich> sure, but I want to make it work, then make it friendly
[05:23:27] <petev> sure
[05:23:36] <jmkasunich> you can't put "stepgen=0x400" in the RAM, because its too big
[05:23:47] <jmkasunich> so I need to define the compact binary representation
[05:24:00] <jmkasunich> my problem right now is that I don't have the compact binary representation for GPIO
[05:24:02] <petev> so right now you seem pretty happy with the stream format, is that correct?
[05:24:29] <petev> ok, so the stream format is ok, but you need a more compact binary format for gpio?
[05:24:32] <jmkasunich> such as it is - I've only defined the stream format for a single entity - stepgen
[05:24:52] <petev> I think the stream should follow the same syntax for all modules
[05:24:57] <petev> so it may need some thought
[05:25:03] <jmkasunich> different modules will have differnet needs
[05:25:08] <petev> without the same syntax, the tool will be ugly
[05:25:19] <petev> different needs, but same syntax
[05:25:24] <jmkasunich> for a stepgen, the only info you need to convey is "it exists, at address foo, and the user wants it enabled"
[05:25:28] <petev> like different programs, but all in C
[05:25:52] <petev> so maybe there is a structure with certain attributes
[05:26:15] <petev> but you have to distile it to something primitive that uses the same syntax
[05:27:03] <jmkasunich> are you talking about the syntax of the 1K block? or the input syntax for a high level tool that generates a 1K block?
[05:27:27] <petev> the input syntax the user will write
[05:27:40] <jmkasunich> ok, thats why we keep talking past one another
[05:27:57] <jmkasunich> I have absolutely no interest whatsoever in that syntax at this point in time
[05:28:15] <jmkasunich> I care only about the 1K syntax, because I'm writing the driver code that will read the 1K
[05:28:23] <petev> ok
[05:28:28] <jmkasunich> for now, I'm generating the 1K manually
[05:29:03] <jmkasunich> I certainly don't want to come up with a 1K format that will cripple a later tool
[05:29:28] <jmkasunich> but the primary requirements for the 1K syntax are that it be compact, and at least a little bit logical
[05:29:36] <petev> isn't whats described on line 33 of the pastebin the 1K format?
[05:29:57] <jmkasunich> yes, partly
[05:30:01] <petev> are you not quite happy with what you have there yet?
[05:30:10] <jmkasunich> the part labeled "blocks" is general though
[05:30:43] <jmkasunich> a block that describes a stepgen is 5 bytes long, and the meaning of those 5 bytes is unique to stepgen
[05:31:04] <jmkasunich> the block that describes a GPIO pin is ? blocks long and is unique to GPIO pins - thats whats not defined
[05:31:14] <petev> ok
[05:31:24] <petev> so you just want to focus on the gpio block for now
[05:31:24] <jmkasunich> likewise, the block that describes an encoder is ? bytes long and I have no clue what it will say
[05:31:49] <petev> so first thing is what does your gpio reg model look like?
[05:32:04] <jmkasunich> you mean the actual FPGA contents?
[05:32:18] <petev> I think the part about other modules using the IO cells gets handled by them being enabled and gpio gets them by default
[05:32:28] <petev> the fpga registers for controlling gpio
[05:32:40] <jmkasunich> not cast in stone yet, but something like this:
[05:32:49] <petev> do you have an OE register, a pin register, a data register, etc.
[05:32:55] <jmkasunich> (all of these regs pack in 24 bits)
[05:33:12] <petev> sure, but what regs do you have right now?
[05:33:34] <jmkasunich> output pin reg, input pin reg, oe reg, open-collector enable reg, and inversion registers
[05:34:07] <jmkasunich> 6 bits that define everything the HW can do with a pin
[05:34:07] <petev> so OE and OC are not so orthogonal
[05:34:12] <jmkasunich> no
[05:34:32] <jmkasunich> http://pastebin.ca/494277
[05:34:56] <jmkasunich> lines 27-45 describe those registers (if I choose to simply export everything to HAL)
[05:35:08] <petev> yeah, that's your first cut at the 1K stream for a gpio pin?
[05:35:22] <jmkasunich> lines 1-20 was my first cut
[05:35:45] <jmkasunich> the stream would be "pin-num, 9bit-code"
[05:35:59] <jmkasunich> 9 bits sucks, that makes it 3 bytes per pin
[05:36:00] <petev> and at this point you want the stream pin oriented and the driver will build the 24-bit values?
[05:36:07] <petev> sure
[05:36:06] <jmkasunich> yes
[05:36:30] <petev> ok, let me think on it
[05:36:41] <jmkasunich> the driver will have masks that were generated based on the stream
[05:36:47] <petev> right
[05:37:07] <jmkasunich> some bits of each register will be copied every time from hal pins or params, and merged with the masks, then written to the HW
[05:37:09] <petev> so somewhere a pin address is needed too or some way for the driver to know what pin it is
[05:37:23] <jmkasunich> other bits will come only from the masks, because the HAL pins weren't exported
[05:37:43] <jmkasunich> the pisser is that I really need 6 values, each with 3 possible states
[05:37:47] <jmkasunich> 3 doesn't pack well
[05:37:57] <petev> only in octal ;-)
[05:38:15] <jmkasunich> the states are: fixed-at-1, fixed-at-0, and get-from-hal
[05:38:31] <jmkasunich> 3 states uses 2 bits
[05:39:08] <jmkasunich> output enable: fix at 1, fix at 0, get from hal.... same for oc-mode, output-invert, input-invert
[05:39:46] <jmkasunich> only the get-from-hal case would export the pin or param (obviously)
[05:39:57] <petev> sure, but some of the states of bits may be able to be infered if a simpler view can be presented in the stream
[05:40:15] <jmkasunich> only the non-orthogonal ones
[05:40:19] <petev> right
[05:40:31] <jmkasunich> the oc-oe thing might be compressable from 4 bits down to 3
[05:40:36] <petev> so we need a more orthogonal view in the stream
[05:40:41] <jmkasunich> the inverts can't be compressed
[05:41:01] <petev> how is the pin number assigned? is it strictly by order?
[05:41:24] <jmkasunich> I was planning on "number, code, number, code"
[05:41:30] <jmkasunich> so you could specify them in any order
[05:41:33] <jmkasunich> and even intermix them
[05:41:39] <petev> ok, so this is just the code part?
[05:41:43] <jmkasunich> yes
[05:42:06] <jmkasunich> I suppose the 72 pins (7 bits) could be packed with the 9 bits
[05:42:08] <petev> in the HAL view here, are you departing from the model of drivers exporting both the inverted and non-inverted input?
[05:42:17] <jmkasunich> but that is the kind of thing that really forces you to use a tool
[05:42:36] <jmkasunich> the inverts aren't really for the HAL input/output
[05:42:44] <jmkasunich> cause that can be done in the driver
[05:42:50] <jmkasunich> they're for the dedicated functions
[05:43:05] <petev> what is bit-1 then?
[05:43:15] <jmkasunich> if you need active low step pulses, or your encoder has an active low index, you gotta invert it in the pin-driver
[05:43:48] <jmkasunich> bit 1 and several others are a result of me trying to please everybody
[05:43:57] <petev> hmm, I think the other module needs, pin driver, and gpio are getting mixed together
[05:44:12] <petev> I think if they are separated this will get easier
[05:44:26] <jmkasunich> the stepgen itself could have polarity bits
[05:44:33] <petev> yes
[05:44:47] <petev> and it should control the pin driver when it's enabled
[05:44:55] <jmkasunich> but polarity is something that will get duplicated for just about everthing that can drive or read from an I/O pin
[05:45:01] <jmkasunich> so I wanted to put it in the pin driver
[05:45:10] <jmkasunich> maybe it does make more sense to put it in the modules
[05:45:21] <petev> no, polarity function will live in the pin driver
[05:45:28] <petev> so the HW won't be duplicated
[05:45:38] <petev> gpio will specify pol for pins that are used as gpio
[05:45:49] <petev> stpgen should specify them for it's pins
[05:45:52] <jmkasunich> I thought you just said the opposite
[05:46:04] <petev> both control the pin drivers polarity control pin
[05:46:12] <jmkasunich> han
[05:46:14] <jmkasunich> nah
[05:46:20] <petev> the stream specifies gpio and stepgen, not the pin driver
[05:46:40] <jmkasunich> if a pin is truly GPIO, it doesn't need a hardware inverter at all
[05:46:57] <petev> maybe not if you export both version of the pin
[05:47:08] <jmkasunich> I can invert in HAL - the traditional in and in-not for inputs, and out + out-enable for outputs
[05:47:19] <petev> but all stepgen related stuff should be in the stream block for stepgen
[05:47:24] <jmkasunich> the only reason for the HW invert is for stepgen
[05:47:32] <jmkasunich> and I was being stupid not to just put it in stepgen
[05:47:42] <jmkasunich> see - this is why I like to discuss these things with people
[05:47:44] <petev> that's what I was asking before about departing from the HAL driver model
[05:47:58] <petev> right, put it in stepgen and it's much cleaner
[05:48:36] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/firmware/stepgen.vhd?annotate=1.2
[05:48:48] <jmkasunich> line 211
[05:48:56] <jmkasunich> that defines my registers in the FPGA
[05:49:14] <jmkasunich> I have bits 19-31 available to me, I can easily put invert in there
[05:49:20] <petev> right
[05:49:22] <jmkasunich> hmm, open collector is a bit nastier though
[05:49:44] <petev> each module should pretty much contain all of it's config
[05:50:06] <petev> sometimes that gets a bit ugly with clock divider stuff
[05:50:13] <petev> but I like to stick to that rule
[05:50:32] <petev> you should be able to take a module and use it without a bunch of other module dependancies
[05:50:43] <petev> this is in regards to HDL
[05:50:51] <jmkasunich> I agree pretty much
[05:51:11] <petev> it's makes the SW programmers life easier too
[05:51:22] <jmkasunich> thats why there is a stepgen.vhd, and a 5i2x_stepgen.c - between them they contain all stepgen specific info
[05:51:27] <petev> as the register will usually turn out much nicer
[05:51:49] <petev> except for the invert stuff that is needed and in other registers ;-)
[05:51:59] <jmkasunich> that does double (at least) the number of signals leaving the block
[05:52:08] <petev> yeah, but that's not a big deal
[05:52:11] <jmkasunich> I can do the invert inside the block, so thats not a problem
[05:52:25] <jmkasunich> but for each pin (step, dir) leaving the module, I also need to send an enable
[05:52:33] <petev> you will still need the OE control sigs if it's reauired with stepgen
[05:52:44] <jmkasunich> OE is used to make open-collector
[05:52:55] <petev> right
[05:53:13] <petev> so the IO cell has pin, data, and OE, correct?
[05:53:45] <petev> in gpio mode, maybe you don't need OC mode
[05:54:01] <petev> it's easy to do by setting data to 0, and using OE as the data pin
[05:54:10] <petev> makes the gpio model a bit cleaner
[13:24:18] <lerman_> lerman_ is now known as lerman
[18:33:41] <jepler> it looks like [HAL]SHUTDOWN is only in TRUNK
[18:34:19] <cradek> that's not necessarily what he needs - the spindle turns off when you exit
[18:34:54] <jepler> OK
[18:34:56] <cradek> (I just tried it last night)
[18:35:01] <cradek> but that was trunk I guess
[18:35:09] <jepler> I don't see this noted in the changelogs at http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Released but I'm not saying you're wrong either
[18:35:43] <cradek> hmm
[18:36:28] <cradek> I'm not sure how to test it
[18:37:06] <jepler> without attached hardware, yeah
[18:37:44] <jepler> temporarily add a "halcmd show pin" in the emc runscript at the right point?
[18:37:51] <cradek> I think emc.in rev is the fix
[18:37:51] <jepler> (whereever that point might be)
[18:38:06] <cradek> RELEASE_2_1_2:
[18:38:35] <cradek> maybe it is in the release notes, just not with the keywords you wanted: fix problem with MACHINE ON which was left active on shutdown
[18:39:01] <jepler> yeah I searched for spindle
[19:04:46] <jepler> cradek: in my copy of v2_1_branch I added this to the runscript:
[19:04:46] <jepler> $ grep -A2 "show pin" scripts/emc
[19:04:46] <jepler> $HALCMD show pin motion.spindle
[19:04:46] <jepler> echo "Unloading hal components" >> $DEBUG_FILE
[19:04:46] <jepler> $HALCMD unload all
[19:04:51] <jepler> the "show pin" line, that is
[19:05:12] <jepler> when I run stepper and hit f1 f2 f9 alt-f4 I see this in the terminal output: 05 bit OUT TRUE motion.spindle-on ==> spindle-on
[19:07:06] <cradek> drat
[19:07:10] <cradek> shows what I know
[20:06:44] <cradek> I know it worked on trunk, yesterday, with pluto
[20:07:22] <cradek> maybe some fix is missing in 2.1, or it's just a consequence of the pluto resetting and I mistook it
[20:08:00] <petev> it works on trunk with the motenc-100 in my system as well
[20:08:33] <petev> and some of the other IOs are not cleared, so it's probably not accidental
[20:09:11] <cradek> interesting, thanks
[20:09:52] <cradek> I don't see that kwaj answered my last question
[20:10:42] <cradek> (I was trying to surreptitiously determine whether he successfully updated)
[20:12:16] <petev> I have 2.1.5 installed as well
[20:12:19] <petev> I guess I could run that and try it
[20:12:29] <petev> do you remember the old mod param name for motion?
[22:20:22] <Guest733> Guest733 is now known as skunkworks_
[22:23:15] <skunkworks_> skunkworks_ is now known as skunkworks