Back
[00:04:10] <SWPLinux> ok - it found the board (yay), and said it was going to program a 5i22-1M board, but that the 5i22 isn't supported yet (that's my job)
[00:04:58] <SWPLinux> I guess it's time to ask pete if it's possible to tell the difference between the 1M and the 1.5M boards other than trying to program and seeing if it fails
[00:05:21] <SWPLinux> I'll be back in a little bit. gonna go for a walk and maybe find some food along the way
[00:18:48] <jepler> jmkasunich2_: do rtapi fifos work on rtai, to the best of your knowledge?
[00:21:14] <jepler> hm -- there's no way for a realtime task (a free-running task) to block for a fifo being readable
[00:21:47] <SWPadnos> I think one of the major design goals of HAL was to make it so no RT process blocks for anything
[00:22:17] <jepler> yeah
[00:22:53] <jepler> I'm thinking about 'newinst' -- it's "as simple as" calling a kernelspace function with arguments giving the new instance name
[00:23:01] <jepler> but you don't want to run it in a realtime context
[00:40:55] <SWPadnos> that calling a kernel function (presumably under userpace control) has been a big stumbling block
[00:43:12] <jmkasunich2_> back
[00:43:49] <jmkasunich2_> jepler: at one time fifos worked under rtai
[00:44:00] <jmkasunich2_> but that was a long time ago, and bitrot may have set in
[00:44:20] <jepler> that's OK, during the time you were gone I remembered some of the other reasons that fifos weren't a good match to this problem..
[00:44:41] <jmkasunich2_> ah
[00:44:54] <jmkasunich2_> were you thinking of sending the requests from user space to kernel space thru a fifo?
[00:45:21] <jepler> yeah
[00:46:39] <jmkasunich2_> to be honest I'd like to eliminate fifos (and other unused stuff) from rtapi
[00:47:35] <SWPLinux> fifos can work for userspace commands, but you'd want a separate low priority thread to process them
[00:47:40] <jmkasunich2_> right
[00:47:53] <jmkasunich2_> and you really don't need the buffer aspect of a fifo
[00:47:54] <SWPLinux> that would be part of RTAPI overhead, not part of HAL, so HAL would still not block for any reason
[00:48:12] <SWPLinux> buffering can be helpful - there's no need to remove it
[00:48:13] <jmkasunich2_> IMO it's quite reasonable to make user space wait for one command to complete before issuing another
[00:48:25] <SWPLinux> that's great, for a single user process
[00:48:45] <SWPLinux> dunno ifg multiple processes can attach to a single queue though
[00:49:13] <jmkasunich2_> even for multiple processes, everything needs to be serialized
[00:49:29] <jmkasunich2_> that's done today with mutexes
[00:51:01] <SWPLinux> there are two mechanisms in kernel 2.6.20 that could be useful for user<-> RT comms
[00:51:05] <SWPLinux> one is relayfs
[00:51:09] <SWPLinux> I'm looking for the other
[00:51:55] <jmkasunich2_> I guess one important question to ask is "what level of backwards compatibility do we require"
[00:52:08] <jmkasunich2_> 2.6.20 or later is certainly a demanding requirement
[00:52:38] <jepler> in the (currently-disabled) implementation, a write to /proc kicks off the process; I had some method of making sure that two halcmds weren't making newinst requests at the same time
[00:52:38] <SWPLinux> I don't know where they were added - I just ran across one in xconfig earlier
[00:53:29] <jmkasunich2_> does linux support file locking as a general case?
[00:53:32] <jepler> I forgot the details, but particularly the "now write (read?) a byte to a file in /proc" part seemed to be the part that offended right-thinking people everywhere
[00:53:43] <jmkasunich2_> if one process locks /proc/halcmd
[00:53:51] <jepler> (of course a different implementation was also required for sim, where there are no /proc entries)
[00:54:57] <SWPLinux> crap. I can't find that other one now, and it looked like a good thing
[00:55:04] <SWPLinux> maybe I saw it on the web or something
[00:55:14] <jmkasunich2_> if it depends on a very recent kernel version, it is not a good thing (IMO)
[00:55:41] <SWPadnos> as I said, I'm not sure which version of the kernel it got added in - I just noticed it in 2.6.20 since that's what I'm configuring
[00:55:49] <jmkasunich2_> oh
[00:56:15] <SWPadnos> it would certainly be a post-2.2 thing anyway I think, so it would likely be on 8.04, which will have a post-2.6.20 kernel anyway
[00:56:42] <jmkasunich2_> we shouldn't tie EMC to a specific version of Ubuntu
[00:57:01] <SWPadnos> true
[00:57:09] <jmkasunich2_> although we don't support them as well, people who want to compile EMC2 for <insert-distro-here> should at least have a shot at it
[00:58:09] <jmkasunich2_> it is quite limiting that rtapi must have a feature set that is the least common denominator of RTAI, RTLinux, and the various kernels
[00:58:28] <jmkasunich2_> we did abandon kernel 2.4 didn't we?
[00:58:30] <SWPadnos> 2.6.20 isn't exactly new any more - it was first released in February of this year
[00:58:54] <SWPadnos> they're at 2.6.22.x now, and 2.6.23 is expected soon-ish
[00:58:56] <jmkasunich2_> jmkasunich@decatur:~/emcdev/emc2head$ uname -a
[00:58:56] <jmkasunich2_> Linux decatur 2.6.15-magma #1 Fri Jun 9 20:51:19 EEST 2006 i686 GNU/Linux
[00:59:32] <jmkasunich2_> I have the same thing that most EMC2 users have, and unless there is some huge benefit to Joe Average user, I don't want to for them to change
[00:59:58] <jmkasunich2_> newinst does not qualify as a benefit to Joe Average
[01:00:05] <SWPadnos> there isn't an official Ubuntu kernel 2.6.20 package for 6.06, and we're actually "holding people back" by not releasing newer RT kernels
[01:00:19] <SWPadnos> (there may be a 2.6.20 for 6.06, come to think of it)
[01:01:14] <SWPadnos> I'm not saying we should release new kernels every time there's an update, just pointing out that we're using a pretty old one (June of 2006)
[01:03:02] <jmkasunich2_> linux-image-2.6.15-29 is the latest that I see in Synaptic
[01:04:01] <SWPadnos> ok. I thought they weren't doing updates other than security for 6.06
[01:04:08] <SWPadnos> that's the most stable way to go about it
[01:04:22] <jmkasunich2_> and machine tools should focus on stable
[01:04:28] <SWPadnos> sure
[01:05:15] <SWPadnos> as I pointed out, 2.6.20 was first released 6 months ago, and I wouldn't advocate using it (or later) until we change the distro the liveCD is based on
[01:05:29] <SWPadnos> so it's not an onerous requirement for "great new features"
[01:06:15] <jmkasunich2_> even when we change the liveCD, we will have (hopefully) hundreds of people who are running the current liveCD distro
[01:06:26] <jmkasunich2_> why should we force them into a new kernel?
[01:06:50] <SWPadnos> I don't think I'm advocating that
[01:06:50] <jmkasunich2_> emc 2.2 _must_ (IMO) compile and run on a 6.06 install
[01:07:20] <SWPadnos> sure - for 2.3, we will likely change to 8.04 (the next LTS distro), which will have a newer kernel
[01:08:09] <SWPadnos> in any case - the point is moot at the moment (especially because the features I saw may be in 2.6.15 anyway)
[01:08:16] <jmkasunich2_> ;-)
[01:08:56] <jmkasunich2_> for that matter, RTAPI is basically a snapshot of RTAI and RTLinux capabilities as of about 3 years ago
[01:09:18] <jmkasunich2_> for all I know, recent RTAI has semaphores that work across the user/kernel boundary
[01:09:36] <jmkasunich2_> however, new RTAI scares me
[01:09:54] <jmkasunich2_> I lurk on the RTAI mailing list, and the latest doesn't seem to be the most stable thing ever invented
[01:10:50] <jepler> hah
[01:11:01] <jepler> as though any version has been particularly resilient
[01:11:20] <jmkasunich> well, the version we're using (and the feature set we're using) doesn't seem too bad
[01:12:39] <SWPLinux> the documentation doesn't say where the semaphore functions can be used, or if they're user / kernel / both
[01:12:58] <SWPLinux> at least not that I can see by scanning
[01:13:09] <jmkasunich> the rtapi docs (rtapi.h) says kernel space only
[01:13:25] <jmkasunich> (but you are checking current rtai, right?)
[01:13:32] <SWPLinux> ah - didn't look there :)
[01:14:09] <jmkasunich> heh - if I wrote it, the .h file is the place to look
[01:15:21] <SWPLinux> I hadn't picked up that you looked at rtapi.h - I thought you were talking about some recent rtai.h
[01:15:46] <jmkasunich> no - what I've been saying is that I don't know what recent rtai can do
[01:16:05] <SWPLinux> there are KERNEL checks in rtai_sem.h, but I don't see if that's so you can have semaphores in kernel or userspace, vs. ones that can be seen across the boundary
[01:16:10] <jmkasunich> rtapi says no user/kernel sems because when I wrote it, either RTLinux or RTAI couldn't do that
[01:16:14] <SWPLinux> right
[01:18:09] <jmkasunich> lol -
https://www.rtai.org/documentation/magma/html/api/ - "Generated on Tue Jan 18 22:53:51 2005 for RTAI API"
[01:18:17] <jmkasunich> thats the RTAI api documentation
[01:18:25] <jmkasunich> kinda old
[01:18:28] <SWPLinux> heh
[01:19:53] <jmkasunich> the rtai website basically sucks
[01:20:30] <jmkasunich> at least their old website had a page that explained the versioning
[01:20:39] <jmkasunich> I have no idea what is the "current" version
[01:20:52] <jmkasunich> they've used "magma" and other words, and they've also used numbers
[01:22:02] <SWPLinux> I'm looking at a local copy of magma CVS right now
[01:26:10] <SWPLinux> ok, if you expand "Modules" / "RTAI FIFO module" in the tree, there's a page on semaphores that could be interesting
[01:26:30] <SWPLinux> this is the frame you should get:
https://www.rtai.org/documentation/magma/html/api/group__fifos__sem.html
[01:27:33] <SWPLinux> hmmm. maybe I should make docs here - the local copy has the same date ;)
[01:28:23] <jmkasunich> note that rtf_sem_wait isn't available from kernel space
[01:28:48] <jmkasunich> that means you can't have a low priority "RT" thread that is blocked on the sem waiting for something to do
[01:29:03] <jmkasunich> instead, it must periodically wake up and check the semaphore, then go back to sleep
[01:29:27] <SWPLinux> that's unnecessary - a low priority thread can just poll (the RT executive does this polling anyway for blocked processes)
[01:29:33] <jmkasunich> the period is a tradeoff between cpu usage and responsiveness (imagine a 1000 line hal file that waits for the thread to wake up for every line)
[01:29:57] <jmkasunich> SWPLinux: thats not true
[01:30:18] <jmkasunich> a "real" semaphore doesn't consume any CPU while blocked - it doesn't poll
[01:31:05] <jmkasunich> the OS has a list of tasks that are blocked on the semaphore - when some other task makes a call that releases the semaphore, the OS wakes up the blocked task
[01:31:14] <jmkasunich> otherwise it sleeps indefinitely, there is no polling
[01:32:46] <SWPLinux> sure - the process doesn't use any clock cycles, but the OS task switcher does check the process list every time to see who's able to run, and when the semaphore is released the OS looks at the list of processes waiting to choose which one(s) to wake up
[01:33:12] <SWPLinux> it's not free from a CPU perspective, though it is from a process perspective
[01:33:30] <jmkasunich> any half decent scheduler doesn't waste time that way
[01:34:07] <jmkasunich> blocked tasks are not on the list of ready to run tasks, and only the ready to run list is traversed by the scheduler when deciding what to run next
[01:34:39] <jmkasunich> a "release semaphore" call will transfer formerly blokced tasks to the ready to run list, but that only happens when the sem is released, not on every switch
[01:34:42] <SWPLinux> I guess a semaphore is serial, so a wake-up would only go to the next task in line
[01:34:47] <SWPLinux> sure
[01:36:15] <SWPLinux> I'm not sure the lack of a blocking call in the kernel is a bad thing anyway
[01:36:32] <SWPLinux> you really have to think hard if you want a kernel process to block on a possibly userspace event
[01:37:44] <SWPLinux> as a side note, I think it's kind of funny that you object to polling for commands, but every HAL parameter needs to be polled for changes at every run of every function :)
[01:38:01] <SWPLinux> (one chooses ones optimizations, I guess)
[01:38:39] <jmkasunich> hal components are inherently periodic, halcmd commands are not
[01:39:11] <SWPLinux> sure, but a periodic poll isn't that big a deal, especially if it's in the RTAPI thread management layer
[01:39:29] <jmkasunich> ok, how often would you poll?
[01:39:49] <jmkasunich> when starting EMC, you may have a few hundred halcmd lines to execute as fast as possible
[01:40:00] <jmkasunich> after its started, you will have zero halcmd lines for hours
[01:40:17] <jmkasunich> polling is not the optimal way to handle that kind of load
[01:40:38] <jmkasunich> (it may be the lesser of two evils, but it is not a good)
[01:40:43] <SWPLinux> the actual poll shouldn't take much time at all
[01:40:48] <SWPLinux> heh - I'll buy that
[01:42:01] <SWPLinux> anyway - this isn't the time to optimize a nonexistent function
[01:42:07] <jmkasunich> heh
[01:42:29] <jmkasunich> I've been googling about RT and Linux (different approaches)
[01:42:46] <jmkasunich> in addition to RTAI and RTLinux there is Xenomai, and Adeos
[01:42:55] <jmkasunich> Adeos is a layer on which some of the others build
[01:43:02] <jmkasunich> misc facts:
[01:43:13] <SWPLinux> one of the options I'll play with (once I'm sure I have a usable RTAI-enabled kernel compiled here) is the RT options in the kernel
[01:43:31] <SWPLinux> err - some of the options ...
[01:44:07] <jmkasunich> the RTAI wiki hasn't been updated since December of 2006, if I'm reading it right
[01:45:50] <SWPLinux> that sounds likely
[01:48:55] <jepler> SWPLinux: peterw dropped by on #emc with the answer to your PCI ID question
[01:50:24] <SWPLinux> thanks
[03:38:40] <SWPLinux> jmkasunich, is there a source .vhd fiel that I can actually make into a bitfile? (for the 5i20)
[03:38:44] <SWPLinux> file
[03:39:04] <jmkasunich> I dunno if there's something that works right this instant
[03:39:11] <jmkasunich> there are already 5i20 bitfiles in CVS tho
[03:39:20] <SWPLinux> I'm testing the tools :)
[03:39:22] <SWPLinux> again
[03:39:24] <jmkasunich> oh
[03:39:43] <SWPLinux> toplevel and bus-test both give errors
[03:40:01] <jmkasunich> I'm afraid its been too long since I was messing with it last - I don't remember the status
[03:40:13] <jmkasunich> I'm afraid its broken at the moment
[03:40:34] <jmkasunich> "it" being the makefile and the process that goes from .spec files thru .vhd to .bit
[03:40:49] <jmkasunich> I bet the .vhd to .bit part still works, the trick is to have a suitable .vhd
[03:40:59] <SWPLinux> yeah
[03:41:49] <SWPLinux> hmmm. this version of the xilinx tools doesn't like the ${packages} line in toplevel.vhd
[03:42:14] <jmkasunich> thats because toplevel.vhd isn't valid vhdl
[03:42:29] <SWPLinux> well, that would help explain it :)
[03:42:32] <jmkasunich> the ${} items are where the toolchain will do substitution
[03:42:39] <SWPLinux> ah, right
[03:45:06] <jmkasunich> do you have a "test.vhd" in your checkout?
[03:45:41] <SWPLinux> nope
[03:45:51] <SWPLinux> not in the firmware dir anyway
[03:45:53] <jmkasunich> ok
[03:46:00] <jmkasunich> that one seems to be building
[03:46:18] <jmkasunich> it has some stepgens in it, without the I/O pin config stuff that was giving me fits
[03:46:54] <jmkasunich> but I dunno if the corresponding hal driver works (matches up with the vhdl)
[03:47:23] <jmkasunich> you are looking for something that you can modify a bit and use in the 5i22?
[03:47:56] <SWPadnos> I don't need to be able to use it, just see that the config went right
[03:48:13] <jmkasunich> ah
[03:49:14] <jmkasunich> http://www.pastebin.ca/688015
[03:49:27] <jmkasunich> will need tweaked
[03:49:30] <SWPadnos> after that, getting something that fits the driver would be good, though my first priority will be getting the DAC/ADC interfaces done
[03:49:40] <SWPadnos> ok - thanks
[03:49:52] <jmkasunich> specifically, the --- comments (two dashes is an ordinary comment, three is used by the build system)
[03:50:06] <jmkasunich> change --- device to your device (3s1500....)
[03:50:09] <SWPadnos> ok
[03:50:21] <jmkasunich> and you need a 5i22 specific constraints file
[03:50:26] <jmkasunich> with the appropriate pinout
[03:50:35] <jmkasunich> lines 10 and 11
[03:51:03] <jmkasunich> try it unchanged first, it might want other uncommitted files
[03:51:05] <SWPLinux> yep
[03:51:07] <SWPLinux> ok
[03:51:13] <jmkasunich> make test.usage for a quick test
[03:51:29] <jmkasunich> then make test.bit for the whole place/route (which is still quick, only a few mins)
[03:51:51] <SWPLinux> I skipped straight to test.bit
[03:52:12] <SWPLinux> I do wish I had an SMP kernel at the moment
[03:52:27] <jmkasunich> I don't think it helps, does it?
[03:52:34] <jmkasunich> lets you do other stuff at the same time tho
[03:52:37] <SWPLinux> I think it does with FPGAs
[03:52:47] <SWPLinux> dunno for sure though
[03:53:04] <SWPLinux> I know that older FPGA tools could actually distribute work over a network
[03:53:17] <SWPLinux> well, it worked. o errors, 80 warnings
[03:53:21] <SWPLinux> unused pins I think
[03:53:30] <jmkasunich> yeah, that sounds about right
[03:53:37] <jmkasunich> now you get to make a UCF file or two
[03:53:50] <SWPLinux> yep
[03:54:19] <jmkasunich> copy 5i20-normal.ucf, and revise for the 5i22
[03:54:50] <jmkasunich> you'll have to fix the pin numbers for every pin (obvious) and add 24 more I/Os
[03:55:38] <jmkasunich> actually scratch that last
[03:55:51] <jmkasunich> don't add the 24 more I/Os, because they aren't mentioned in the VHDL
[03:55:54] <SWPLinux> or I could use IOPR24.ucf from the 5i22 stuff pete sent
[03:56:14] <jmkasunich> I'm not sure if everything will match up 100%
[03:56:26] <SWPLinux> I'll see soon
[03:56:38] <jmkasunich> ok
[03:56:55] <jmkasunich> in the long run I want to commit ones based on the 5i20 ones - formatting, naming conventions, etc
[03:57:20] <jmkasunich> there are a lot of comments in there that are helpful
[03:57:57] <SWPLinux> yay - actually, one of the bit files pete sent is for the 1.5M chip
[03:58:06] <jmkasunich> cool
[03:58:36] <jmkasunich> you should be able to invoke the latest bfload with that file, and it should find your board
[03:58:44] <jmkasunich> but it won't load anything since that isn't written yet
[03:59:02] <SWPLinux> that's how I found out what chip the file was for :)
[03:59:03] <jmkasunich> finding the board is a nice milestone itself
[03:59:09] <jmkasunich> ah
[03:59:19] <jmkasunich> so it did detect the board?
[03:59:29] <jmkasunich> printed the pci info, etc
[03:59:40] <SWPLinux> oh - I had checked that earlier. it found the board and all the same memory regions as lspci
[03:59:46] <SWPLinux> so yes, worked first try
[04:00:28] <jmkasunich> good
[04:00:38] <SWPLinux> yep - very good job there
[04:01:09] <SWPLinux> though lspci does show one memory region as disabled, which isn't noticed by upci
[04:01:25] <jmkasunich> isn't noticed because its disabled
[04:01:49] <jmkasunich> I dunno if upci is explicitly testing for enabled regions or not, I bet it is
[04:01:56] <jmkasunich> disabled regions aren't usefull
[04:01:56] <SWPLinux> no - I mean it's printed by bfload, but upci didn't seem to notice the region is disabled
[04:02:13] <SWPLinux> it's found, but the disabled state isn't noticed
[04:02:53] <SWPLinux> oh - nevermind. it's correct
[04:03:16] <SWPLinux> there are 5 regions, 4 of which are listed and one which isn't - the disabled one
[04:03:39] <SWPLinux> the expansion ROM isn't seen because it's disabled
[04:03:40] <jmkasunich> two for the bridge and two for the FPGA, right?
[04:04:02] <jmkasunich> the 64K memory block is the important one, should be region 3
[04:04:35] <SWPLinux> 256 bytes mem, two 256-byte I/O, 64k mem and disabled 64k expansion ROM
[04:04:41] <SWPLinux> yep - region 3 is the 64k block
[04:05:34] <jmkasunich> oh, I guess for config loading that isn't the most important region
[04:06:17] <jmkasunich> I was thinking of post-config loading of the RAM block, and HAL driver access to the FPGA
[04:06:17] <SWPLinux> heh
[04:06:52] <jmkasunich> you get to figure out how to access the USERo/ and USERi/ pins of the bridge chip
[04:07:06] <SWPLinux> luckily I have code for that :)
[04:07:17] <SWPLinux> the SC5i21 program should be the same
[04:09:38] <jmkasunich> hmm, it's tomorrow
[04:09:44] <jmkasunich> and I'm yawning
[04:09:50] <SWPadnos> indeed
[04:09:54] <jmkasunich> time for bed I think
[04:10:01] <SWPadnos> ok. thanks for the help again
[04:10:20] <jmkasunich> thanks for getting me involved in this - I needed (and may still need) something to get me off top-dead-center and moving again
[04:10:36] <SWPadnos> any time
[04:10:51] <SWPadnos> I know it helps to get some interesting detail to hook you back in
[04:11:01] <SWPadnos> that certainly helps for me
[17:21:42] <SWPLinux> jmkasunich, question for you
[17:22:14] <SWPLinux> bfload never sets the direction of the GPIO bits on the 9030, is that an oversight or is it done somewhere else?
[17:27:08] <jepler> jmkasunich: any insight into whether setting stepgen accel & vel limits has a benefit, assuming it's being commanded by something that obeys vel & accel limits (emc)
[17:29:19] <SWPLinux> jepler: it seems skunkworks found that the accel needed to be set, but vel could be set to 0
[17:31:06] <SWPLinux> I think he tried setting accel to 0 (instant rate change) and to "infinity" (rate slews to new value over one stepgen_update cycle)
[17:31:15] <SWPLinux> if not, then bad skunkworks! :)
[18:32:57] <SWPLinux> one other question on bfload: there are supposed to be a few extra clocks at the end to get the FPGA to finish loading - I don't see where they're done (unless there's extra data in the bitfile)
[18:44:27] <jmkasunich> jepler: stepgen uses the accel limit value to "tune" the "pre-tuned position loop"
[18:45:59] <jmkasunich> if your commands are already limited, you can have the vel limit set to infinity in either position or velocity mode, and the accel limit set to infinity in velocity mode only
[18:46:29] <jmkasunich> SWPLinux: the 9030 is already configured, I think by an on-board serial prom
[18:46:33] <SWPLinux> ok - I think that's what skunkworks saw
[18:46:37] <SWPLinux> ok
[18:47:06] <SWPLinux> the reset state isn't correct (from the datasheet), but if there's a SEEPROM to set it, that's good
[18:47:26] <jmkasunich> re the extra clocks, I think I determined that they aren't needed, by the time it gets done clocking in the last of the checksum bytes, DONE is already high
[18:47:37] <SWPLinux> pete's 9054 code for the 5i21 explicitly sets the direction bits
[18:47:48] <SWPLinux> ok
[18:48:01] <jmkasunich> the 9030 and 9054 configs could be completely different
[18:48:17] <SWPLinux> yep
[18:48:22] <SWPLinux> that's my concern :)
[18:49:01] <SWPLinux> I'm trying to do a 3-way merge between the datasheet, the 5i20 program function, and the 5i21 function - just making sure I understand what's going on :)
[18:49:11] <jmkasunich> sounds like fun
[18:49:25] <SWPLinux> heh - not!
[18:49:35] <SWPLinux> almost there though
[19:10:52] <SWPLinux> well, it says it worked. I don't have a method of verifying that at the moment though
[19:12:49] <jmkasunich> loading one of peter's files?
[19:12:54] <SWPLinux> yep
[19:13:18] <jmkasunich> you have the 7i31 LED board right?
[19:13:26] <SWPLinux> yes
[19:13:38] <SWPLinux> I think this config is supposed to blink the onboard LEDs as well
[19:13:50] <jmkasunich> I'm gonna make a ucf file and commit it, then we can do quickie configs
[19:14:05] <SWPLinux> sounds good to me
[19:14:07] <jmkasunich> for instance, it would be easy to do a config that turns on every other light
[19:14:12] <SWPLinux> I'll commit this as well
[19:14:15] <jmkasunich> no bus interface or driver at all
[19:15:07] <SWPLinux> just something that goes blinky blinky would suffice for checking programming
[19:15:25] <jmkasunich> every other light on is even easier than blinking
[19:15:33] <jmkasunich> unless you want to blink at 16MHz
[19:16:28] <SWPLinux> just use a 32-bit counter and send bits 5 through 28 or so to all the I/O ports
[19:16:46] <jmkasunich> yeah
[19:17:11] <jmkasunich> ucf file is the bottleneck, I'll get cracking on that
[19:17:14] <SWPLinux> there's a LEDBLINK.VHD file that does that in the 5i22 zip file
[19:17:29] <SWPLinux> that's why I think this config should be blinking the onboard LEDs
[19:17:39] <SWPLinux> I'll pull the cover off this case and see if that's happening
[19:18:43] <SWPLinux> yep - they're going blinky blinky
[19:18:47] <SWPLinux> woohoo!
[19:18:50] <jmkasunich> yay
[19:19:11] <SWPLinux> oh, and I can see them through the vent holes in the side of the case - even better :)
[19:20:03] <SWPLinux> ok, milestone 1 reached - yay and thanks for the help so far
[19:20:17] <jmkasunich> you're welcome
[19:20:23] <jmkasunich> and thanks for helping me get out of a rut
[19:20:33] <SWPLinux> you're very welcome
[19:21:12] <SWPLinux> if you want to make a generic UCF file, I'm happy to move on to the ADxxx chip drivers :)
[19:21:19] <jmkasunich> ok
[19:21:25] <SWPLinux> there are soem pin files in the 5i22 archive
[19:21:28] <SWPLinux> some
[19:21:39] <jmkasunich> right, I'm fetching that now
[19:21:53] <SWPLinux> ok. there are UCF files as well
[19:23:27] <SWPLinux> I guess it might make sense to make a little test app that lets you write values to registers in a PCI range
[19:23:54] <jmkasunich> that would be pretty quick to do with upci
[19:23:58] <SWPLinux> yep
[19:32:50] <SWPLinux> is there a set of python bindings for upci, or is bfload expected to do all the work of writing configs and RAM blocks?
[19:33:14] <jmkasunich> no python for upci
[19:33:25] <jmkasunich> I'm not sure I understand the 2nd half of the question
[19:34:05] <SWPLinux> oh - writing a RAM block to a card would be easy in the python config script, if there's a upci interface
[19:34:09] <SWPLinux> (for python)
[19:34:23] <jmkasunich> bfload loads both .bit files (plain xilinx format) and .fpga files (xilinx format with extra chunks, one chunk has the RAM content to be loaded, and bfload loads that if present)
[19:34:42] <SWPLinux> ok
[19:34:53] <jmkasunich> the python never interacts with the hardware, and can run on a non-rt box
[19:35:03] <jmkasunich> it produces a .fpga file
[19:35:03] <SWPLinux> right
[19:56:36] <jmkasunich> hmm, the 5i22 has a LCLK period constraint of 20nS = 50MHz
[19:56:49] <jmkasunich> the 5i20 has 29.5nS = 33 MHz
[19:57:00] <jmkasunich> I'm almost certain that LCLK is supposed to be the PCI clock at 33MHz
[19:58:55] <jmkasunich> duh
[19:58:57] <jmkasunich> rtfm
[19:59:08] <jmkasunich> the 5i22 uses 48MHz for the local bus clock
[20:00:05] <SWPLinux> right - there's a 48 MHz crystal on the board
[20:01:22] <jmkasunich> the 5i20 has a 50MHz vrystal, but uses 33MHz from the PCI bus for the local bus clock
[20:01:47] <SWPLinux> hmmm
[20:02:21] <SWPLinux> I guess the constraint should be the worst case, so forthe 5i20 it should be 20 ns
[20:02:25] <jmkasunich> the 48MHz clock makes the timing constraints tighter, but I bet the spartan3 is faster, so it works out in then end
[20:02:39] <SWPLinux> yeah, the spartan3 should be a bir faster
[20:02:41] <SWPLinux> bit
[20:02:48] <jmkasunich> no, the 5i20 has two clock nets, and the constraints are applied to each net individually
[20:03:48] <SWPLinux> ok
[20:11:54] <jmkasunich> arg - CVS branches
[20:12:04] <SWPLinux> heh
[20:12:28] <jmkasunich> I have my firmware directory on a branch "mesa-configtools"
[20:12:50] <jmkasunich> just did the cvs add for the new ucf files, and they'll be added _to the branch_ when I commit
[20:13:10] <SWPLinux> makes sense
[20:13:22] <jmkasunich> I want them in head too (I think)
[20:13:26] <jmkasunich> so you can use them
[20:13:36] <SWPLinux> let's make sure one or more of them works first :)
[20:13:42] <jmkasunich> although it might make sense for you to be on the same branch
[20:13:58] <SWPLinux> I have the configtools branch in my checkout, or I wouldn't have the latest makefile etc.
[20:14:18] <SWPLinux> I think I did that only at the mesa_5i2x dir and below
[20:14:35] <jmkasunich> oh good
[20:14:38] <jmkasunich> you are the same as me then
[20:14:40] <SWPLinux> so the utils (like bfload and the tester) go into main
[20:14:42] <SWPLinux> yep
[20:15:06] <jmkasunich> I'm hacking up test.vhd to see if the 5i22 constraint files work
[20:15:11] <jmkasunich> if so I'll commit them (to the branch)
[20:15:27] <SWPLinux> ok, great
[20:16:13] <SWPLinux> I'm midway through a program that takes a card number, card type, PCI region, offset, and value on the command line, and does the obvious thing
[20:16:25] <SWPLinux> I'm only supporting 32-bit writes at the moment, I think
[20:16:38] <jmkasunich> hmm, do you know the complete part number for the chip (including the dash number for the speed grade)?
[20:16:45] <SWPLinux> one sec
[20:17:06] <jmkasunich> re: 32 bit access - thats all I ever intend to support
[20:17:28] <SWPLinux> 4C is the last line
[20:17:36] <SWPLinux> that's the speed grade, right?
[20:17:37] <jmkasunich> the 5i20 had multiple regions of different widths, the 5i22 only has 32 bit wide memory mapped (and I think an I/O mapped region, but not using that either)
[20:18:02] <jmkasunich> 2s200pq208-5 is how the 5i20 device is specified
[20:18:10] <SWPLinux> that's not how it is on this one
[20:18:15] <SWPLinux> lemme look at the manual
[20:18:27] <jmkasunich> I'm guessing that 3s1500fg320-4 might be the number for the 5i22
[20:18:51] <SWPadnos> no, it's got a lot of stuff in between
[20:18:54] <SWPadnos> but 4 is the grade
[20:18:58] <SWPadnos> see page 6 of the spartan3 manual
[20:19:18] <SWPadnos> the full part number is:
[20:19:24] <jmkasunich> Usage report:
[20:19:24] <jmkasunich> Selected Device : 3s1500fg320-4
[20:19:33] <jmkasunich> it looks like the toolchain accepted it
[20:20:07] <SWPadnos> XC3S1500
[20:20:09] <SWPadnos> FG320EGQ0705
[20:20:10] <SWPadnos> A3050673A
[20:20:12] <SWPadnos> 4C
[20:20:21] <SWPadnos> ok, that may be the format the tools expect
[20:20:37] <SWPadnos> must be some low percentages in there :)
[20:20:40] <jmkasunich> Number of Slices: 687 out of 13312 5%
[20:20:40] <jmkasunich> Number of Slice Flip Flops: 1003 out of 26624 3%
[20:20:40] <jmkasunich> Number of 4 input LUTs: 975 out of 26624 3%
[20:20:40] <jmkasunich> Number of IOs: 118
[20:20:40] <jmkasunich> Number of bonded IOBs: 38 out of 221 17%
[20:20:42] <jmkasunich> Number of BRAMs: 1 out of 32 3%
[20:20:44] <jmkasunich> Number of GCLKs: 1 out of 8 12%
[20:21:08] <SWPLinux> what config is that?
[20:21:24] <jmkasunich> that "test.vhd" that I pastebinned for you yesterday
[20:21:28] <SWPadnos> ok
[20:21:36] <jmkasunich> changed the --- device and --- constraints lines only
[20:21:43] <jmkasunich> I think that is some number of stepgens
[20:22:03] <jmkasunich> yep, 6 of them, plus a bus interface and config ram
[20:22:29] <SWPadnos> hmmm. so only ~120 stepgens would fit in the chip. too bad ;)
[20:22:43] <SWPadnos> well, more because there would still be only one bus interface and such
[20:22:58] <jmkasunich> I just discovered that the first step (which makes the usage report) doesn't access the ucf file
[20:23:08] <jmkasunich> when I went to the next step I got an error, troubleshooting now
[20:23:27] <SWPadnos> I noticed yesterday that the usage target seemed to echo the whole report, then the usage again
[20:24:11] <jmkasunich> the whole report goes to stdout (IIRC), then the usage target extracts one snippet of it, saves that to foo.usage, and cat's foo.usage
[20:24:31] <SWPadnos> ok. I thought it suppressed the massive output
[20:25:04] <jmkasunich> eventually we might want to do that, but for some of the less massive and more time-consuming steps, the output lets you know what is going on
[20:25:10] <SWPadnos> yep
[20:25:15] <jmkasunich> certainly the error messages are handy if something goes wrong
[20:25:15] <SWPadnos> especially if there's an error
[20:26:02] <jmkasunich> oh, the errors I have are simple - the vhdl doesn't reference IOBits[72] thru [95] but they are in the constraints file
[20:26:08] <jmkasunich> easy to fix that
[20:26:12] <SWPadnos> heh
[20:26:16] <SWPadnos> add more stepgens ;)
[20:26:32] <jmkasunich> even easier
[20:26:40] <jmkasunich> IOBits: inout std_logic_vector (95 downto 0);
[20:27:29] <SWPadnos> heh
[20:29:50] <jmkasunich> darn, didn't meet timing
[20:30:46] <SWPadnos> bummer
[20:30:52] <jmkasunich> clock to output
[20:31:25] <jmkasunich> not gonna sweat it right now, what matters is that the constraint file seems OK
[20:33:12] <jmkasunich> odd
[20:33:15] <SWPLinux> ?
[20:33:21] <jmkasunich> cvsweb shows those files as in the "Attic"
[20:33:29] <jmkasunich> even when I select the mesa-configtools branch
[20:34:28] <jmkasunich> if you do a cvs up, do you get them?
[20:35:14] <SWPadnos> lemme check
[20:36:21] <SWPadnos> hmmm
[20:37:22] <SWPLinux> strange. I think I don't have the branch checked out here
[20:37:58] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head/src/hal/drivers/mesa_5i2x/firmware$ cat CVS/Tag
[20:37:58] <jmkasunich> Tmesa-configtools
[20:38:05] <jmkasunich> do you get that?
[20:38:13] <SWPLinux> the only thing we've been changing back and forth has been bfload, so it wouldn't have seemed to be an issue
[20:38:25] <jmkasunich> bfload isn't in that branch
[20:38:29] <SWPLinux> no, I have no Tag file
[20:38:44] <SWPLinux> right - that's why I wouldn't have noticed ithis weekend
[20:38:43] <jmkasunich> more accurately, that branch doesn't exist except in a few directories
[20:39:37] <jmkasunich> my checkout is in the branch only for mesa_5i2x/ and mesa_5i2x/firmware/
[20:39:59] <jmkasunich> I wish I could recall the command I issued to do that
[20:40:19] <SWPLinux> cvs up -r mesa-configtools -dP
[20:40:27] <SWPLinux> (that's what I just did anyway ;) )
[20:40:32] <jmkasunich> in mesa_5i2x I assume
[20:40:36] <SWPLinux> yep
[20:40:45] <jmkasunich> that got you the two new .ucf files?
[20:40:54] <SWPLinux> yep
[20:41:02] <jmkasunich> cool
[20:41:05] <SWPLinux> plus a few other changes
[20:41:29] <jmkasunich> now you have what I have
[20:41:37] <jmkasunich> (dunno if that is a good thing or not)
[20:41:45] <SWPLinux> eh
[20:41:47] <SWPLinux> heh
[20:45:32] <SWPLinux> interesting:
[20:45:34] <SWPLinux> Number of Slices: 682 out of 13312 5%
[20:45:36] <SWPLinux> Number of Slice Flip Flops: 997 out of 26624 3%
[20:45:38] <SWPLinux> Number of 4 input LUTs: 974 out of 26624 3%
[20:45:38] <SWPLinux> Number of IOs: 118
[20:45:41] <SWPLinux> Number of bonded IOBs: 38 out of 221 17%
[20:45:41] <SWPLinux> Number of BRAMs: 1 out of 32 3%
[20:45:44] <SWPLinux> Number of GCLKs: 1 out of 8 12%
[20:45:45] <SWPLinux> that's without changing the iobits size
[20:45:57] <SWPLinux> note that the usage is somewhat lower than you had
[20:46:34] <SWPLinux> and it appears to have met timing
[20:47:40] <SWPLinux> though that was "make test5i22.usage", not doing bitfile generation (dunno if that matters)
[20:57:44] <jmkasunich> 5 less slices, 6 less FFs, not much of a difference
[20:58:03] <jmkasunich> you didn't place and route, so you don't know anything about timing
[20:58:17] <jmkasunich> (usage only runs the very first step of the toolchain to get that report)
[20:58:19] <SWPLinux> ok - you did "make test.bit"?
[20:58:22] <jmkasunich> yes
[20:58:24] <SWPLinux> ah
[20:58:39] <jmkasunich> the 2nd stage is where the ucf file is added to the mix
[20:58:53] <jmkasunich> that's when it will error out if you don't expand IOBits from 72 to 96
[20:59:01] <SWPLinux> ok - running that now (I did expand it)
[20:59:24] <jmkasunich> back an a couple hours
[20:59:32] <SWPLinux> ok. see you then
[20:59:38] <SWPLinux> unless I go out to eat or something :)
[23:31:06] <jepler> * jepler is playing with git again. 15:48:05 <SWPLinux> though that was "make test5i22.usage", not doing bitfile generation (dunno if that matters)
[23:31:08] <jepler> er
[23:31:09] <jepler> http://git.unpy.net/view?p=stepconf.git;a=summary
[23:31:24] <SWPadnos> heh
[23:31:49] <jepler> also I made some progress on stepconf today
[23:31:59] <SWPadnos> great
[23:32:01] <SWPadnos> !
[23:32:34] <jepler> it's really unfortunate that it requires gnome (not just gtk)
[23:32:48] <jepler> because gtk doesn't have a "wizard"-like widget in the version in dapper
[23:33:02] <SWPadnos> hmmm
[23:33:17] <SWPadnos> is there a tab notebookkind of widget?
[23:33:32] <jepler> I'm sure there are ways to
[23:33:36] <jepler> "fake" it..
[23:34:24] <SWPadnos> is gnome needed for glade, or for the resulting executable?
[23:34:32] <jepler> for the resulting script
[23:34:49] <jepler> it's a runtime requirement, not (only) a build-time one
[23:35:05] <SWPadnos> bummer
[23:37:42] <jepler> newer gtk have GtkAssistant, but in the version on dapper there's only GnomeDruid
[23:38:01] <SWPadnos> that means almost nothing to me :)
[23:38:03] <jepler> http://library.gnome.org/devel/gtk/unstable/GtkAssistant.html
[23:38:13] <jepler> they're different implementations of what you know as a wizard
[23:38:42] <SWPadnos> how new does GTK need to be?
[23:38:59] <jepler> 2.10
[23:39:02] <SWPadnos> I suppose that doesn't matter, if the latest for dapper doesn't have it
[23:39:39] <jepler> it might be in backports but that's a worse "additional requirement" than gnome, given that everybody but a few kde hardcore types already has gnome installed
[23:40:00] <jepler> otoh, it means that by 2010 it'll be possible to switch to GtkAssistant
[23:40:06] <SWPadnos> ok, so it's in the gnome on dapper, just not in gtk alone
[23:40:10] <SWPadnos> heh
[23:40:12] <jepler> right
[23:40:55] <SWPadnos> well, once you get past the onerousness of requiring X fora machine controller, a few extra window managers shouldn't be a big deal