Back
[03:10:37] <jmkasunich> I have an interesting logic problem for yous guys
[03:10:59] <jmkasunich> given a list of addresses (with some no-care bits) like this:
[03:11:00] <jmkasunich> cs11xxxxxxxxxxxx
[03:11:00] <jmkasunich> cs10xxxxxxxxxxxx
[03:11:00] <jmkasunich> cs01xxxxxxxxxxxx
[03:11:00] <jmkasunich> cs001111111xxxxx
[03:11:00] <jmkasunich> cs001111110111xx
[03:11:01] <jmkasunich> cs001111110110xx
[03:11:03] <jmkasunich> cs001111110101xx
[03:11:08] <jmkasunich> cs00111111010011
[03:11:09] <jmkasunich> cs00111111010010
[03:11:34] <jmkasunich> build vhdl logic to generate chip selects
[03:11:44] <jmkasunich> that go true when the address bus matches the pattern
[03:11:53] <jmkasunich> efficiently of course
[03:16:58] <cradek> I'll do the first one
[03:17:23] <jmkasunich> no, you gotta do the whole set
[03:17:39] <jepler> is the problem to do "common subexpression elimination", so that the 4th and subsequent lines share the same logic for "first two bits are zero"?
[03:17:40] <cradek> what's chris morley's id?
[03:17:44] <jmkasunich> the key to efficiency is recognizing common chunks and only decoding them once
[03:18:05] <jmkasunich> jepler: yes
[03:18:41] <jmkasunich> although you'd want to share logic for all the bits that are common, not just the first two
[03:18:55] <jepler> er, yes
[03:19:04] <jepler> I offer to let someone else do it
[03:19:07] <jepler> 'night guys
[03:19:13] <jmkasunich> goodnight
[03:21:22] <jmkasunich> I keep thinking there ought to be a python string function that returns N such that "the first N chars of these two strings match"
[03:24:59] <cradek> seems like a very simple loop to write...
[03:25:13] <jmkasunich> the "first N match" thing?
[03:25:20] <cradek> yeah
[03:25:25] <jmkasunich> it is
[03:25:47] <jmkasunich> but I don't want to re-invent the wheel - py seems to have lots of good string processing already
[03:26:01] <jmkasunich> besides, I'm not entirely sure thats the function I need
[03:26:36] <jmkasunich> lets see.... each output (one per line) will be one LUT, thats unavoidable
[03:26:51] <jmkasunich> a LUT can do any function of 4 bits
[03:28:04] <jmkasunich> so if I need 1010001xx, I can say "output true when the three bits right before the xx are 001, and a fourth bit (cascade from higher order decode) is 1
[03:28:51] <jmkasunich> or I can have it compare two bits, and two cascades
[13:09:05] <jepler> jmkasunich: is this something like what you were looking for?
http://pastebin.ca/513828
[13:09:38] <jepler> output on your sample set of chip selects:
http://pastebin.ca/513831
[13:09:53] <jepler> I doubt I got the vhdl syntax right though
[13:10:16] <jepler> er, hm -- something's missing from there
[13:19:23] <jepler> second try:
http://pastebin.ca/513850
[17:00:33] <petev> alex_joni, u there?
[17:01:16] <petev> cradek, u there?
[17:21:56] <jmkasunich> jepler: you go to bed too early, and wake up too early
[17:28:49] <jmkasunich> your solution is significantly shorter than mine
[17:29:35] <jmkasunich> it relies more on the synthesis software for optimization though - some of your selects are cascades of many levels
[17:30:45] <jmkasunich> if I trusted the synth software thats probably actually the right approach
[17:31:37] <jmkasunich> my version uses no more than three levels of logic, and no level has more than 4 inputs (so it maps to an FPGA LUT)
[17:32:21] <petev> jmkasunich, how much do you know about the EMC NML messages?
[17:32:29] <jmkasunich> next to nothing
[17:32:33] <jmkasunich> I don't do NML
[17:32:43] <petev> not the NML part, the EMC part
[17:32:48] <jmkasunich> I don't do NML
[17:32:55] <petev> is alex the expert?
[17:33:24] <jmkasunich> the real experts are Fred and Will at NIST, but alex is probalby the closest we have
[17:33:32] <petev> ok
[17:33:49] <petev> I don't think NML itself is that bad, but the way EMC uses it looks pretty ugly
[17:34:16] <petev> I see lots of stuff that appears to be duplicate functionality, way too many mesages that should be a single message
[17:34:30] <petev> and the status reporting looks a bit strange
[17:35:30] <petev> there are a bunch of sub status data that is agregated, but each of the sub-status is declared as an NML message instead of just a simple struct
[17:35:56] <petev> it makes me wonder if they aren't sent by themselves sometimes, and sent agregated at other times
[17:36:45] <petev> maybe it was done to encapsulate the update() method
[17:41:38] <alex_joni> petev: I am now
[17:41:44] <petev> hey alex
[17:41:47] <alex_joni> hey petev
[17:41:50] <petev> got a few NML questions
[17:41:59] <alex_joni> hope I can answer them
[17:42:11] <petev> first, I can't seem to find any messages dealing with RS274 params/variables
[17:42:18] <petev> do you know if there are any?
[17:42:25] <alex_joni> what kind of params?
[17:42:34] <jepler> there aren't any
[17:42:37] <alex_joni> you talking about #5xxx ?
[17:42:38] <jmkasunich> I don't think the interp uses NML at all
[17:42:38] <jepler> if you mean to get/set the values of #1234
[17:42:41] <alex_joni> there aren't any
[17:42:42] <petev> yes
[17:42:48] <jmkasunich> task calls interp, interp returns canonicals
[17:42:51] <petev> ok, that answers that
[17:43:01] <jmkasunich> only when the canonicals get invoked does NML get into the picture
[17:43:01] <petev> next question
[17:43:51] <petev> I think there are some cases where you might want to set RS274 params from a GUI, especially with future functionality in mind
[17:44:03] <petev> next question is regarding the status reporting
[17:44:04] <alex_joni> that might be pretty hard to do
[17:44:13] <alex_joni> think about order of interpreting/execution
[17:44:34] <petev> I don't see the issue
[17:44:35] <alex_joni> do you want to set the param before the program gets interpreted/run? that might still make sense
[17:44:44] <petev> yes
[17:44:44] <jepler> you can set with mdi commands
[17:44:57] <alex_joni> if you change a param during the run, the interpreter might already have passed what you need
[17:45:01] <petev> jepler, I guess thats a good work around
[17:45:07] <jepler> you can get (kinda) with special comments (DEBUG,#1234)
[17:45:34] <jmkasunich> hi jepler
[17:45:37] <jepler> hi jmkasunich
[17:45:38] <petev> alex_joni, I wasn't thinking for use with a running program
[17:45:56] <alex_joni> petev: I know.. just trying to think of possible problems here
[17:46:05] <petev> many commercial controls set certain behavior based on parameter values, I was thinking more along these lines
[17:46:24] <petev> regarding the status, I see an aggregated status block being reported
[17:46:34] <petev> but the sub-status blocks are also NML messages
[17:46:41] <petev> are they ever sent by themselves?
[17:46:50] <petev> was this done just for the update() method?
[17:46:53] <alex_joni> petev: not that I know of
[17:47:07] <petev> ok, I'll have to dig into the code some more
[17:47:24] <alex_joni> for data encapsulation, and modularity
[17:47:36] <petev> also, there appears to be much duplicated functionality and too many messages that could be easily handled by one
[17:48:00] <petev> alex_joni, I don't mind the su-status, I'm wondering why they are NML messages
[17:48:17] <alex_joni> petev: my guess is that they were done with the java codegen
[17:48:18] <petev> for instance, why do we have so many msgs for spindle control?
[17:48:31] <petev> alex_joni, oh, that would explain it
[17:48:43] <petev> do we want to clean up some of the messages?
[17:48:55] <alex_joni> petev: I started to
[17:49:01] <petev> its also a real pain to have separate messages for on/off
[17:49:06] <alex_joni> but then I realized there's not much point for it
[17:49:17] <alex_joni> it's not a big waste of memory/data
[17:49:18] <petev> at a minimum those should be a single message
[17:49:28] <alex_joni> and the overhead for programmers is not that hard either
[17:49:33] <petev> but it's ugly to interface too
[17:49:40] <petev> look at the spindle messages
[17:49:43] <alex_joni> at best we would decrease the number by half
[17:49:46] <petev> there are so many that appear to be redundant
[17:49:53] <alex_joni> but break backwards compatibility
[17:50:00] <petev> true
[17:50:05] <alex_joni> I'm not sure that's a better situation
[17:50:24] <alex_joni> petev: trust me, I felt exactly the same way as you do now
[17:50:29] <alex_joni> when I started looking at this
[17:50:43] <petev> hmm, it makes it difficult for a new programmer to understand the NML interface
[17:51:01] <alex_joni> I'm not so sure less messages would make it easier
[17:51:26] <petev> it would certainly make it more clear which is the correct message to use
[17:51:43] <alex_joni> yes.. and no :P
[17:51:52] <petev> which should be used for spindle control? On, Off, Forward, Reverse, Halt, Disable... ?
[17:52:04] <alex_joni> at lest in my experience I very seldom was able to understand what message I should use
[17:52:16] <alex_joni> only by looking at the name
[17:52:37] <alex_joni> petev: most of those aren't for the user anyway
[17:52:47] <petev> aslo, why is there a base class for each msg type that usually does nothing and there is only one derived class?
[17:52:59] <alex_joni> they are generated by task (based on the interp) and get sent to the io controller
[17:53:11] <petev> I see
[17:53:15] <alex_joni> petev: codegen is my guess
[17:53:23] <alex_joni> what I do agree we should have
[17:53:25] <alex_joni> is a separation
[17:53:39] <petev> of user and internal ?
[17:53:43] <alex_joni> in the NML files, have the UI part separately from the internal stuff
[17:53:44] <alex_joni> yeah
[17:53:52] <petev> yes, that would be a very good start
[17:53:58] <petev> and use separate header files
[17:54:01] <alex_joni> we can probably do that without changing anything
[17:54:07] <petev> than internal stuff could change at will
[17:54:08] <alex_joni> weeell..
[17:54:35] <alex_joni> separate headers will be a bit of a problem because of those derived stuff
[17:55:07] <alex_joni> gotta run for a while (half an hour), still doing some post-wedding stuff
[17:55:24] <alex_joni> but I'll be back soon, and we can continue this (it's going into a nice direction :D)
[17:55:34] <petev> let me look at it some more, if I can figure out which ones are internal vs user, then we can understand the impact better
[17:55:48] <alex_joni> petev: let me give you a link
[17:55:49] <petev> I have to run too, will be back later tonight
[17:55:52] <petev> sure
[17:56:49] <alex_joni> * alex_joni is digging
[17:57:52] <alex_joni> http://www.robcon.ro/emc/nml/NML%20messages%20usage%20desc.csv
[17:58:01] <alex_joni> might be a tiny bit old
[17:58:03] <petev> ok, thanks
[17:58:12] <alex_joni> openoffice should open it just fine
[17:58:39] <alex_joni> some NML analysis I did a while ago
[17:59:11] <alex_joni> btw, wedding was great.. had the president to wish us all the best :D
[18:00:00] <petev> so you are married now?
[18:00:25] <alex_joni> yeap.. since last night :)
[18:00:38] <petev> congratulations
[18:00:55] <petev> what are you doing on here?
[18:01:07] <petev> you are going to be in the dog house quickly ;-)
[18:01:26] <alex_joni> ha :D
[19:15:51] <alex_joni> hi guys
[19:19:42] <jmkasunich> hi
[19:19:52] <jmkasunich> aren't you having a wedding today?
[19:20:13] <jmkasunich> oh, yesterday
[19:23:21] <alex_joni> had it yesterday
[19:23:47] <alex_joni> and it was pretty nice too :)
[19:23:56] <jmkasunich> good
[19:24:00] <jmkasunich> congradulations
[19:24:13] <alex_joni> is that a typo or on purpose?
[19:24:24] <jmkasunich> typo
[19:24:28] <alex_joni> I noticed skunkworks said the same thing
[19:24:35] <jmkasunich> its a common typo
[19:24:37] <alex_joni> oh, ok then :D
[19:25:09] <jmkasunich> "congradulations on your gratuation from school" ;-)
[19:25:20] <alex_joni> haha
[19:25:36] <alex_joni> well.. the strangest thing happend last night :)
[19:25:43] <jmkasunich> lol
[19:25:51] <alex_joni> not that !!
[19:26:06] <jmkasunich> I should hope that happened too
[19:26:08] <alex_joni> had the president drive by our wedding, and he stopped and wished us all the best
[19:26:14] <jmkasunich> wow
[19:26:25] <alex_joni> yeah ;) not quite the most common thing
[19:26:28] <jmkasunich> our president wouldn't do that
[19:26:36] <alex_joni> our's is like that
[19:26:49] <jmkasunich> good
[19:26:52] <alex_joni> but he's usually in our capital.. about 400 miles away
[19:27:00] <alex_joni> he was here for a soccer final
[19:27:12] <alex_joni> and he stayed at a hotel near the place
[21:26:36] <jepler> yay, stuart says his homing is now working
[21:37:29] <jmkasunich> finally
[22:02:09] <alex_joni> jepler:
http://www.filpro.de/gcode/gcode_german.html
[22:33:50] <cradek> that's nice to see
[23:25:38] <jepler> two thoughts: 1, a GPL notice should be added to gcode.html. 2, let's include that file with emc if the translator will GPL it