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