From icculus at clutteredmind.org Sat Jun 1 09:39:31 2002 From: icculus at clutteredmind.org (Ryan C. Gordon) Date: Sat, 1 Jun 2002 09:39:31 -0400 (EDT) Subject: Congrats. Message-ID: You're being slashdotted. :) --ryan. From mrochuk at ee.ualberta.ca Sat Jun 1 12:25:14 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 01 Jun 2002 10:25:14 -0600 Subject: [manticore] Congrats. In-Reply-To: References: Message-ID: <1022948714.1556.2.camel@lucid> Nothing wrong with that... Jeff On Sat, 2002-06-01 at 07:39, Ryan C. Gordon wrote: > > You're being slashdotted. :) > > --ryan. > > > From mrochuk at ee.ualberta.ca Sat Jun 1 12:42:51 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 01 Jun 2002 10:42:51 -0600 Subject: [manticore] Congrats. In-Reply-To: <1022948714.1556.2.camel@lucid> References: <1022948714.1556.2.camel@lucid> Message-ID: <1022949771.1551.7.camel@lucid> Okay I'm probably not going to get any mailing list mail for a but, because I'm moving today, and I need to wait for my hostname to update, to my new IP. Although last time it only took about 10 min Jeff On Sat, 2002-06-01 at 10:25, Jeff Mrochuk wrote: > Nothing wrong with that... > > Jeff > > On Sat, 2002-06-01 at 07:39, Ryan C. Gordon wrote: > > > > You're being slashdotted. :) > > > > --ryan. > > > > > > > > From mrochuk at ee.ualberta.ca Mon Jun 3 01:34:17 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 02 Jun 2002 23:34:17 -0600 Subject: Update Message-ID: <1023082457.1094.17.camel@lucid> Alright, now that I'm all moved in, and we probably have some new subscribers, I'll post an update. I've been working on increasing the efficiency of the SDRAM controller, which is going well but I have yet to do any extensive testing. Benj is going to increase the flexibility of the display unit to support multiple resolutions. Haven't heard from andrew in a while. Once you're done with that triangle thing, maybe you can take a look at textures, or whatever you think would be interesting. The biggest load of work is going to be rewriting vga_fifo_ctrl to support our new sdram controller and display unit. A few people have emailed me saying they subscribed to the list and haven't seen much activity, likely because we don't have a lot of developers, and plenty to keep us busy. Either way this is a relaxed list, and you can feel free to post suggestions even if you aren't working on it. Of course we're still really filling in the base of the project before we add a lot of features. Man, what a boring post. Jeff From jmrochuk at ieee.org Wed Jun 5 14:28:00 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Wed, 5 Jun 2002 12:28:00 -0600 Subject: Opencore Message-ID: <20020605182800.GA28923@lucid.digitaljunkies.ca> Do you think I should go through and clean up all the naming conventions before we add the project/code to opencores? Or should we just commit it all now and clean it up as we go. I see no harm in adding it, may get us some more contributers. Jeff -- From jmrochuk at ieee.org Wed Jun 5 15:34:03 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Wed, 5 Jun 2002 13:34:03 -0600 Subject: FIFO Message-ID: <20020605193403.GA29947@lucid.digitaljunkies.ca> I think I'm going to work on a fully generic FIFO so we can get rid of those Altera specific fifos. Jeff -- From jmrochuk at ieee.org Wed Jun 5 18:10:12 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Wed, 5 Jun 2002 16:10:12 -0600 Subject: [manticore] FIFO In-Reply-To: <20020605193403.GA29947@lucid.digitaljunkies.ca> References: <20020605193403.GA29947@lucid.digitaljunkies.ca> Message-ID: <20020605221012.GA32078@lucid.digitaljunkies.ca> the fifo is now in CVS in the rtl/vhdl/manticore_fifo/ dir Its not quite finished yet, and when it is I'll do several simulations. Its implemented much like a software stack, its just a block of data with a start and end pointer, so no data has to move around, itself. This is probably how all fifos are implemented, but hey, I thought I was pretty clever. Benj, any signal feature requests, say 3/4 full or something? Right now it has a full and empty signal, synch clear, asynch reset. Jeff On Wed, Jun 05, 2002 at 01:34:03PM -0600, Jeff Mrochuk wrote: > I think I'm going to work on a fully generic FIFO so we can get rid of > those Altera specific fifos. > > Jeff > -- -- From benjcarson at digitaljunkies.ca Wed Jun 5 18:23:57 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Wed, 05 Jun 2002 16:23:57 -0600 Subject: FIFO In-Reply-To: <20020605221012.GA32078@lucid.digitaljunkies.ca> References: <20020605193403.GA29947@lucid.digitaljunkies.ca> <20020605221012.GA32078@lucid.digitaljunkies.ca> Message-ID: <20020605222357.5C771898A@ns1.digitaljunkies.ca> > Benj, any signal feature requests, say 3/4 full or something? > Right now it has a full and empty signal, synch clear, asynch reset. > 1/2 full? I think we might use that somewhere and perhaps a level signal (that basically reports the difference between the read & write "pointers"). That one might be slightly tricky to implement generically and to optimize. Actually, you could just use an up/down counter that is wide enough to register the depth of the fifo... What do you think? Benj From benjcarson at digitaljunkies.ca Wed Jun 5 18:29:48 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Wed, 05 Jun 2002 16:29:48 -0600 Subject: OpenCores In-Reply-To: <20020605221012.GA32078@lucid.digitaljunkies.ca> References: <20020605193403.GA29947@lucid.digitaljunkies.ca> <20020605221012.GA32078@lucid.digitaljunkies.ca> Message-ID: <20020605222948.10AF7898A@ns1.digitaljunkies.ca> Have you been following/contributing to the discussions on OC? I haven't really, save for that first post a while ago. I don't see any harm in starting the project there. We might as well bring it over but maybe mention that we still have a lot of cleaning up to do. (Probably be good to say that we're students so that when people see some of the kludge in vga_fifo_ctrl they understand...) Benj From luisgtz at megared.net.mx Wed Jun 5 19:02:57 2002 From: luisgtz at megared.net.mx (Luis Gutierrez) Date: 05 Jun 2002 18:02:57 -0500 Subject: Tools In-Reply-To: <20020605222948.10AF7898A@ns1.digitaljunkies.ca> References: <20020605193403.GA29947@lucid.digitaljunkies.ca> <20020605221012.GA32078@lucid.digitaljunkies.ca> <20020605222948.10AF7898A@ns1.digitaljunkies.ca> Message-ID: <1023318177.2215.1.camel@dunedain.megared.net.mx> Hi! I'm read about the manticore project in slashdot. I'm very interested and would like to participate. However, I'ts been a while since I did anything in vhdl. I was wondering what tools do you use to write and simulate the project. thanks! From mrochuk at ee.ualberta.ca Wed Jun 5 19:14:21 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 05 Jun 2002 17:14:21 -0600 Subject: [manticore] Tools In-Reply-To: <1023318177.2215.1.camel@dunedain.megared.net.mx> References: <20020605193403.GA29947@lucid.digitaljunkies.ca> <20020605221012.GA32078@lucid.digitaljunkies.ca> <20020605222948.10AF7898A@ns1.digitaljunkies.ca> <1023318177.2215.1.camel@dunedain.megared.net.mx> Message-ID: <1023318862.6433.1.camel@lucid> For the actual coding we use emacs. Any text editor is fine. Since we're using the Altera Excalibur board we're pretty much limited to Quartus II for compilation and simulation. We also don't have access to any other commercial compilers. Jeff On Wed, 2002-06-05 at 17:02, Luis Gutierrez wrote: > > Hi! > > I'm read about the manticore project in slashdot. I'm very interested > and would like to participate. However, I'ts been a while since I did > anything in vhdl. I was wondering what tools do you use to write and > simulate the project. > > thanks! > > > From mrochuk at ee.ualberta.ca Wed Jun 5 20:46:44 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: Wed, 5 Jun 2002 18:46:44 -0600 Subject: FIFO issues Message-ID: <3D00EACC@webmail.ualberta.ca> Here's one for ya. I tried to compile my fifo, and even with only 32x8 its gigantic (14% of our chip) So I took a look at their design and it turns out the reason its so small is because it uses ESB bits. If you disable ESB bits on the altera fifo, our 640x8 fifo is 103% of the chip. Looks like we may have to be a bit more creative in our display, maybe empty it as it fills. I'd like to know how commercial hardware does it, maybe it just has giant fifo hardware. In the mean time, do you know if you can tell quartus to use ESB bits on your own designs? Jeff From Bloodwars at aol.com Wed Jun 5 21:10:45 2002 From: Bloodwars at aol.com (Bloodwars at aol.com) Date: Wed, 05 Jun 2002 21:10:45 -0400 Subject: A few questions Message-ID: <41CA7F26.79BA244F.022B1F45@aol.com> Aaron Elliott, 19, EE/CompSci major, Virginia wondering where i can get quartus II... i have electronic workbench if that would work... do i actually have to buy a board from altera for their software? I was wondering... wouldn't it be a better idea to determine what the card should do before starting a design? I can see that this is better in that there will always be a working product, but also see having to rewrite design when limits are reached... I've built a scanner, calculator, and really crappy version of an 8086, and it seems easier to get designs after inputs and outputs are defined... Oh yeah, and with inputs and outputs defined, write some algorithms and run it through a nice cluster for four years ;) Anyways, my two cents, i know some knowledge can be worse than none, maybe once the basics are done, modules can be determined and worked on (ram, controllers, parts of the gpu, whatever outputs needed, etc) (i'm not heavily experienced in designs of this scale i guess, hoping to learn as i go, hopefully help some too ;) Sorry for writting too much, Aaron From mrochuk at ee.ualberta.ca Wed Jun 5 21:48:33 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 05 Jun 2002 19:48:33 -0600 Subject: [manticore] A few questions In-Reply-To: <41CA7F26.79BA244F.022B1F45@aol.com> References: <41CA7F26.79BA244F.022B1F45@aol.com> Message-ID: <1023328113.697.3.camel@lucid> On Wed, 2002-06-05 at 19:10, Bloodwars at aol.com wrote: > Aaron Elliott, 19, EE/CompSci major, Virginia > > wondering where i can get quartus II... i have electronic workbench if that would work... do i actually have to buy a board from altera for their software? > There's a Quartus II web edition v 2.0 available for free on Altera's site. > I was wondering... wouldn't it be a better idea to determine what the card should do before starting a design? > I can see that this is better in that there will always be a working product, but also see having to rewrite design when limits are reached... I've built a scanner, calculator, and really crappy version of an 8086, and it seems easier to get designs after inputs and outputs are defined... > Oh yeah, and with inputs and outputs defined, write some algorithms and run it through a nice cluster for four years ;) > We do have everything pretty much defined. This may not be clear on the web page, but we've done a lot of communicating on what features we're going to have. In retrospect we probably should have done some C/C++ testing for alot of our algorithms to make sure everything works, but things worked themselves out. At the moment we're working on increasing the flexibility and feature set of the design. Basically we have a decent, but simple 3d chip, which can render, but only at 8bit color and a fixed resolution. Once we increase the flexibility, and add communication (via PCI) we'll be in good shape. > Anyways, my two cents, i know some knowledge can be worse than none, maybe once the basics are done, modules can be determined and worked on (ram, controllers, parts of the gpu, whatever outputs needed, etc) > > (i'm not heavily experienced in designs of this scale i guess, hoping to learn as i go, hopefully help some too ;) > > Sorry for writting too much, > Aaron > > No problem, your input is welcomed. Jeff From breuter at lucent.com Wed Jun 5 21:51:15 2002 From: breuter at lucent.com (Brian Reuter) Date: Wed, 05 Jun 2002 21:51:15 -0400 Subject: Architecture etc. References: <41CA7F26.79BA244F.022B1F45@aol.com> <1023328113.697.3.camel@lucid> Message-ID: <3CFEC013.EED46C76@lucent.com> Hi Jeff, I'm a multi-skilled hardware guy. I've done ASICs and FPGAs for a bunch of systems (including various memory controllers), and I can also do boards. I'm curious what you need done and if there are some more detailed architectural documents available. Thanks, Brian Reuter From mrochuk at ee.ualberta.ca Wed Jun 5 22:45:24 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 05 Jun 2002 20:45:24 -0600 Subject: [manticore] Architecture etc. In-Reply-To: <3CFEC013.EED46C76@lucent.com> References: <41CA7F26.79BA244F.022B1F45@aol.com> <1023328113.697.3.camel@lucid> <3CFEC013.EED46C76@lucent.com> Message-ID: <1023331524.697.11.camel@lucid> At the moment we're not really sure what the next logical feature is. The main issue now is that because project was originally done for school, it had deadlines. The limited time available let to some ugly code and hackish stuff. Right now me and benj are trying to clean up the code base, so it'll be much more organized for other developers to contribute. Unfortunately all the documentation available is what is on the site, although the code is usually well commented. Our current goals that aren't really spoken for are these: 4. develop PCI interface (Or interface with an existing one) 5. add normal support to the rasterizer (facing/backfacing information + basic lighting) 6. implement vertex lighting 7. implement texture mapping 8. add 2D support (lines, basic polygons, hardware cursor) 9. develop board design If you'd like to help out in anyway it'd be greatly appreciated, these are all fairly long term and a lot of work. The only problem is that trying to work on these at the moment may be difficult since the base is being changed. Jeff On Wed, 2002-06-05 at 19:51, Brian Reuter wrote: > Hi Jeff, > > I'm a multi-skilled hardware guy. I've done ASICs and FPGAs for a bunch of > systems (including various memory controllers), and I can also do boards. I'm > curious what you need done and if there are some more detailed architectural > documents available. > > Thanks, > > Brian Reuter > From benjcarson at digitaljunkies.ca Thu Jun 6 00:15:23 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Wed, 05 Jun 2002 22:15:23 -0600 Subject: FIFO issues In-Reply-To: <3D00EACC@webmail.ualberta.ca> References: <3D00EACC@webmail.ualberta.ca> Message-ID: <20020606041523.B1C62898A@ns1.digitaljunkies.ca> You have to use lpm_ram as registers to use esb bits, as far as I know. I don't think using lpm_ram is too vendor specific since I think most FPGAs have ram or can emulate it using normal registers. Just my $0.02. Benj Jeff Mrochuk writes: > Here's one for ya. > > I tried to compile my fifo, and even with only 32x8 its gigantic (14% of our > chip) > So I took a look at their design and it turns out the reason its so small is > because it uses ESB bits. If you disable ESB bits on the altera fifo, our > 640x8 fifo is 103% of the chip. > > Looks like we may have to be a bit more creative in our display, maybe empty > it as it fills. I'd like to know how commercial hardware does it, maybe it > just has giant fifo hardware. > > In the mean time, do you know if you can tell quartus to use ESB bits on your > own designs? > > Jeff > > From mrochuk at ee.ualberta.ca Thu Jun 6 00:18:33 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 05 Jun 2002 22:18:33 -0600 Subject: [manticore] Re: FIFO issues In-Reply-To: <20020606041523.B1C62898A@ns1.digitaljunkies.ca> References: <3D00EACC@webmail.ualberta.ca> <20020606041523.B1C62898A@ns1.digitaljunkies.ca> Message-ID: <1023337113.696.14.camel@lucid> I'll look into doing it with lpm ram. On Wed, 2002-06-05 at 22:15, benjcarson at digitaljunkies.ca wrote: > You have to use lpm_ram as registers to use esb bits, as far as I know. I > don't think using lpm_ram is too vendor specific since I think most FPGAs > have ram or can emulate it using normal registers. Just my $0.02. > > Benj > > > Jeff Mrochuk writes: > > > Here's one for ya. > > > > I tried to compile my fifo, and even with only 32x8 its gigantic (14% of our > > chip) > > So I took a look at their design and it turns out the reason its so small is > > because it uses ESB bits. If you disable ESB bits on the altera fifo, our > > 640x8 fifo is 103% of the chip. > > > > Looks like we may have to be a bit more creative in our display, maybe empty > > it as it fills. I'd like to know how commercial hardware does it, maybe it > > just has giant fifo hardware. > > > > In the mean time, do you know if you can tell quartus to use ESB bits on your > > own designs? > > > > Jeff > > > > > > From benjcarson at digitaljunkies.ca Thu Jun 6 00:22:26 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Wed, 05 Jun 2002 22:22:26 -0600 Subject: FIFO issues In-Reply-To: <3D00EACC@webmail.ualberta.ca> References: <3D00EACC@webmail.ualberta.ca> Message-ID: <20020606042226.98BE3898A@ns1.digitaljunkies.ca> Another thought: we should probably look into seeing if we can get a sample of a RAMDAC and move some of our FIFOs off the FPGA. That might solve some issues and free us from using Altera-specific stuff. All at the cost of more interfacing though. Whoopee! Next time I've got a spare minute or two at work I'll have a look at Digikey and see what I can dig up... Benj Jeff Mrochuk writes: > Here's one for ya. > > I tried to compile my fifo, and even with only 32x8 its gigantic (14% of our > chip) > So I took a look at their design and it turns out the reason its so small is > because it uses ESB bits. If you disable ESB bits on the altera fifo, our > 640x8 fifo is 103% of the chip. > > Looks like we may have to be a bit more creative in our display, maybe empty > it as it fills. I'd like to know how commercial hardware does it, maybe it > just has giant fifo hardware. > > In the mean time, do you know if you can tell quartus to use ESB bits on your > own designs? > > Jeff > > From mrochuk at ee.ualberta.ca Thu Jun 6 00:39:47 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 05 Jun 2002 22:39:47 -0600 Subject: [manticore] Re: FIFO issues In-Reply-To: <20020606041523.B1C62898A@ns1.digitaljunkies.ca> References: <3D00EACC@webmail.ualberta.ca> <20020606041523.B1C62898A@ns1.digitaljunkies.ca> Message-ID: <1023338387.610.1.camel@lucid> Come to think of it lpm_ram should work fine. The read and write signals can be directly wired (maybe with a few gates for control) and the addresses being access will be the pointers. I'll give it a shot tommorow. On Wed, 2002-06-05 at 22:15, benjcarson at digitaljunkies.ca wrote: > You have to use lpm_ram as registers to use esb bits, as far as I know. I > don't think using lpm_ram is too vendor specific since I think most FPGAs > have ram or can emulate it using normal registers. Just my $0.02. > > Benj > > > Jeff Mrochuk writes: > > > Here's one for ya. > > > > I tried to compile my fifo, and even with only 32x8 its gigantic (14% of our > > chip) > > So I took a look at their design and it turns out the reason its so small is > > because it uses ESB bits. If you disable ESB bits on the altera fifo, our > > 640x8 fifo is 103% of the chip. > > > > Looks like we may have to be a bit more creative in our display, maybe empty > > it as it fills. I'd like to know how commercial hardware does it, maybe it > > just has giant fifo hardware. > > > > In the mean time, do you know if you can tell quartus to use ESB bits on your > > own designs? > > > > Jeff > > > > > > From jmrochuk at ieee.org Thu Jun 6 13:40:41 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Thu, 6 Jun 2002 11:40:41 -0600 Subject: Opencores Message-ID: <20020606174041.GA12305@lucid.digitaljunkies.ca> Benj, check out the project page and tell me if it needs anything http://www.opencores.org/projects/manticore/ Also we can post a news update on the front page announcing the new project if we like. I put you down as a maintainer, so you should be able to edit the project page. I don't want to put the cvs up there until we get rid of the altera specific code, which is really just the fifos. The PLL isn't necessary other than on the excalibur board. Jeff -- From jmrochuk at ieee.org Thu Jun 6 14:56:57 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Thu, 6 Jun 2002 12:56:57 -0600 Subject: FIFO Message-ID: <20020606185657.GA13523@lucid.digitaljunkies.ca> Mission accomplished, using LPM_RAM I've got the design to be much smaller and faster. A compilable version will be in CVS soon. Of course I still have to simulate and make sure that it works. Then of course I could have used LPM_FIFO. But that would be too easy. Jeff -- From benjcarson at digitaljunkies.ca Thu Jun 6 16:39:26 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Thu, 06 Jun 2002 14:39:26 -0600 Subject: Opencores In-Reply-To: <20020606174041.GA12305@lucid.digitaljunkies.ca> References: <20020606174041.GA12305@lucid.digitaljunkies.ca> Message-ID: <20020606203926.44CF38989@ns1.digitaljunkies.ca> Looks good. Are we going to use their cvs too or should we just point people to icculus? Benj Jeff Mrochuk writes: > Benj, check out the project page and tell me if it needs anything > > http://www.opencores.org/projects/manticore/ > > Also we can post a news update on the front page announcing the new > project if we like. > > I put you down as a maintainer, so you should be able to edit the > project page. > > I don't want to put the cvs up there until we get rid of the altera > specific code, which is really just the fifos. The PLL isn't necessary > other than on the excalibur board. > > Jeff > -- From jmrochuk at ieee.org Thu Jun 6 16:45:44 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Thu, 6 Jun 2002 14:45:44 -0600 Subject: [manticore] Re: Opencores In-Reply-To: <20020606203926.44CF38989@ns1.digitaljunkies.ca> References: <20020606174041.GA12305@lucid.digitaljunkies.ca> <20020606203926.44CF38989@ns1.digitaljunkies.ca> Message-ID: <20020606204544.GA15231@lucid.digitaljunkies.ca> It might be easier to just use icculus, but it doesn't really matter to me. On Thu, Jun 06, 2002 at 02:39:26PM -0600, benjcarson at digitaljunkies.ca wrote: > Looks good. Are we going to use their cvs too or should we just point > people to icculus? > > Benj > > Jeff Mrochuk writes: > > >Benj, check out the project page and tell me if it needs anything > > > >http://www.opencores.org/projects/manticore/ > > > >Also we can post a news update on the front page announcing the new > >project if we like. > > > >I put you down as a maintainer, so you should be able to edit the > >project page. > > > >I don't want to put the cvs up there until we get rid of the altera > >specific code, which is really just the fifos. The PLL isn't necessary > >other than on the excalibur board. > > > >Jeff > >-- > -- From benjcarson at digitaljunkies.ca Thu Jun 6 17:17:00 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Thu, 06 Jun 2002 15:17:00 -0600 Subject: Opencores In-Reply-To: <20020606204544.GA15231@lucid.digitaljunkies.ca> References: <20020606174041.GA12305@lucid.digitaljunkies.ca> <20020606203926.44CF38989@ns1.digitaljunkies.ca> <20020606204544.GA15231@lucid.digitaljunkies.ca> Message-ID: <20020606211700.375A08989@ns1.digitaljunkies.ca> Well, if there is an easy way to mirror cvs then we might as well use both, since icculus isn't exactly known for it's hardware projects. Probably would be pretty easy to throw together a script that'd mirror them. Until we come up with something clever though, I say we stick with icculus for now. Benj Jeff Mrochuk writes: > It might be easier to just use icculus, but it doesn't really matter to > me. > > On Thu, Jun 06, 2002 at 02:39:26PM -0600, benjcarson at digitaljunkies.ca wrote: >> Looks good. Are we going to use their cvs too or should we just point >> people to icculus? >> >> Benj >> >> Jeff Mrochuk writes: >> >> >Benj, check out the project page and tell me if it needs anything >> > >> >http://www.opencores.org/projects/manticore/ >> > >> >Also we can post a news update on the front page announcing the new >> >project if we like. >> > >> >I put you down as a maintainer, so you should be able to edit the >> >project page. >> > >> >I don't want to put the cvs up there until we get rid of the altera >> >specific code, which is really just the fifos. The PLL isn't necessary >> >other than on the excalibur board. >> > >> >Jeff >> >-- >> > > -- From benjcarson at digitaljunkies.ca Thu Jun 6 17:20:35 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Thu, 06 Jun 2002 15:20:35 -0600 Subject: Emails In-Reply-To: <20020606204544.GA15231@lucid.digitaljunkies.ca> References: <20020606174041.GA12305@lucid.digitaljunkies.ca> <20020606203926.44CF38989@ns1.digitaljunkies.ca> <20020606204544.GA15231@lucid.digitaljunkies.ca> Message-ID: <20020606212035.96990898A@ns1.digitaljunkies.ca> One more thing... Did you reply to the two emails that we got directly last weekend? If not one of us probably should. As an aside: it looks like Analog Devices hav RAMDACs, although I'm having difficulty seeing what the difference is between them and VDACs. The datasheet is 44 pages long, so it's taking me a while to get through, but it seems like it's just a beefier version of what Ben & Dave used. You can check it here: http://products.analog.com/products/info.asp?product=ADV7160. Benj From jmrochuk at ieee.org Thu Jun 6 17:50:38 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Thu, 6 Jun 2002 15:50:38 -0600 Subject: [manticore] Emails In-Reply-To: <20020606212035.96990898A@ns1.digitaljunkies.ca> References: <20020606174041.GA12305@lucid.digitaljunkies.ca> <20020606203926.44CF38989@ns1.digitaljunkies.ca> <20020606204544.GA15231@lucid.digitaljunkies.ca> <20020606212035.96990898A@ns1.digitaljunkies.ca> Message-ID: <20020606215038.GA16348@lucid.digitaljunkies.ca> I responded to the last two emails, I might have missed one, I'll check my inbox and take a look. On Thu, Jun 06, 2002 at 03:20:35PM -0600, benjcarson at digitaljunkies.ca wrote: > One more thing... Did you reply to the two emails that we got directly > last weekend? If not one of us probably should. > > As an aside: it looks like Analog Devices hav RAMDACs, although I'm having > difficulty seeing what the difference is between them and VDACs. The > datasheet is 44 pages long, so it's taking me a while to get through, but > it seems like it's just a beefier version of what Ben & Dave used. You can > check it here: > http://products.analog.com/products/info.asp?product=ADV7160. > Benj -- From jmrochuk at ieee.org Fri Jun 7 11:40:35 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Fri, 7 Jun 2002 09:40:35 -0600 Subject: fifo chaos Message-ID: <20020607154035.GA631@lucid.digitaljunkies.ca> fifo appears to be working, more extensive testing required. So did the altera fifo have a read latency? The LPM_RAM has a two cycle latency, which isn't a big issue. It means one line will take 642 cycles to read instead of 640 Jeff -- From benjcarson at digitaljunkies.ca Fri Jun 7 12:04:26 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Fri, 07 Jun 2002 10:04:26 -0600 Subject: fifo chaos In-Reply-To: <20020607154035.GA631@lucid.digitaljunkies.ca> References: <20020607154035.GA631@lucid.digitaljunkies.ca> Message-ID: <20020607160426.E9D238961@ns1.digitaljunkies.ca> The fifo had no latency that I know of. It was dual ported however, but since the two clocks were related to one another we got away with not having to synchronize (pipeline) the inputs and outputs. I wasn't aware that lpm_ram had latency associated with it other than the fact that data shows up on the wires one cycle after a read signal is asserted. Benj Jeff Mrochuk writes: > fifo appears to be working, more extensive testing required. > > So did the altera fifo have a read latency? The LPM_RAM has a two cycle > latency, which isn't a big issue. It means one line will take 642 > cycles to read instead of 640 > > Jeff > -- From jmrochuk at ieee.org Fri Jun 7 12:52:23 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Fri, 7 Jun 2002 10:52:23 -0600 Subject: [manticore] Re: fifo chaos In-Reply-To: <20020607160426.E9D238961@ns1.digitaljunkies.ca> References: <20020607154035.GA631@lucid.digitaljunkies.ca> <20020607160426.E9D238961@ns1.digitaljunkies.ca> Message-ID: <20020607165223.GA1705@lucid.digitaljunkies.ca> Okay the 8x640 fifo is 119MHz and about 120 (~1%) logic blocks on the 20K160E with the same speed grade. The latency must be in the LPM_RAM, because the data lines connect structurally outside of a process, as are the read and write enables. I'm also using the dual port ram. I'll look into it though. I only have one clock at the moment, but its easy to add another. Jeff On Fri, Jun 07, 2002 at 10:04:26AM -0600, benjcarson at digitaljunkies.ca wrote: > The fifo had no latency that I know of. It was dual ported however, but > since the two clocks were related to one another we got away with not > having to synchronize (pipeline) the inputs and outputs. > > I wasn't aware that lpm_ram had latency associated with it other than the > fact that data shows up on the wires one cycle after a read signal is > asserted. > > > Benj > > > Jeff Mrochuk writes: > > >fifo appears to be working, more extensive testing required. > > > >So did the altera fifo have a read latency? The LPM_RAM has a two cycle > >latency, which isn't a big issue. It means one line will take 642 > >cycles to read instead of 640 > > > >Jeff > >-- > -- From benjcarson at digitaljunkies.ca Fri Jun 7 12:54:31 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Fri, 07 Jun 2002 10:54:31 -0600 Subject: fifo chaos In-Reply-To: <20020607165223.GA1705@lucid.digitaljunkies.ca> References: <20020607154035.GA631@lucid.digitaljunkies.ca> <20020607160426.E9D238961@ns1.digitaljunkies.ca> <20020607165223.GA1705@lucid.digitaljunkies.ca> Message-ID: <20020607165431.DEBB18961@ns1.digitaljunkies.ca> Yeah, a second clock shouldn't be a problem if the ram is dual-ported. Actually, can't you set some parameters in lpm_ram to get it to handle two different clocks already? I seem to remember reading that at one point... Benj Jeff Mrochuk writes: > Okay the 8x640 fifo is 119MHz and about 120 (~1%) logic blocks on the > 20K160E with the same speed grade. The latency must be in the LPM_RAM, > because the data lines connect structurally outside of a process, as are > the read and write enables. I'm also using the dual port ram. > > I'll look into it though. I only have one clock at the moment, but its > easy to add another. > > Jeff > > On Fri, Jun 07, 2002 at 10:04:26AM -0600, benjcarson at digitaljunkies.ca wrote: >> The fifo had no latency that I know of. It was dual ported however, but >> since the two clocks were related to one another we got away with not >> having to synchronize (pipeline) the inputs and outputs. >> >> I wasn't aware that lpm_ram had latency associated with it other than the >> fact that data shows up on the wires one cycle after a read signal is >> asserted. >> >> >> Benj >> >> >> Jeff Mrochuk writes: >> >> >fifo appears to be working, more extensive testing required. >> > >> >So did the altera fifo have a read latency? The LPM_RAM has a two cycle >> >latency, which isn't a big issue. It means one line will take 642 >> >cycles to read instead of 640 >> > >> >Jeff >> >-- >> > > -- From jmrochuk at ieee.org Fri Jun 7 13:05:46 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Fri, 7 Jun 2002 11:05:46 -0600 Subject: [manticore] Re: fifo chaos In-Reply-To: <20020607165431.DEBB18961@ns1.digitaljunkies.ca> References: <20020607154035.GA631@lucid.digitaljunkies.ca> <20020607160426.E9D238961@ns1.digitaljunkies.ca> <20020607165223.GA1705@lucid.digitaljunkies.ca> <20020607165431.DEBB18961@ns1.digitaljunkies.ca> Message-ID: <20020607170546.GB1705@lucid.digitaljunkies.ca> Yep, I'm using Dual Ported dual clock ram, the only issue is that my pointers need to be controlled by the clock. I'll have to have the end pointer on one clock, and the start on the other clock. May make for some interesing stuff. Jeff On Fri, Jun 07, 2002 at 10:54:31AM -0600, benjcarson at digitaljunkies.ca wrote: > Yeah, a second clock shouldn't be a problem if the ram is dual-ported. > Actually, can't you set some parameters in lpm_ram to get it to handle two > different clocks already? I seem to remember reading that at one point... > > Benj > > > Jeff Mrochuk writes: > > >Okay the 8x640 fifo is 119MHz and about 120 (~1%) logic blocks on the > >20K160E with the same speed grade. The latency must be in the LPM_RAM, > >because the data lines connect structurally outside of a process, as are > >the read and write enables. I'm also using the dual port ram. > > > >I'll look into it though. I only have one clock at the moment, but its > >easy to add another. > > > >Jeff > > > >On Fri, Jun 07, 2002 at 10:04:26AM -0600, benjcarson at digitaljunkies.ca > >wrote: > >>The fifo had no latency that I know of. It was dual ported however, but > >>since the two clocks were related to one another we got away with not > >>having to synchronize (pipeline) the inputs and outputs. > >> > >>I wasn't aware that lpm_ram had latency associated with it other than the > >>fact that data shows up on the wires one cycle after a read signal is > >>asserted. > >> > >> > >>Benj > >> > >> > >>Jeff Mrochuk writes: > >> > >>>fifo appears to be working, more extensive testing required. > >>> > >>>So did the altera fifo have a read latency? The LPM_RAM has a two cycle > >>>latency, which isn't a big issue. It means one line will take 642 > >>>cycles to read instead of 640 > >>> > >>>Jeff > >>>-- > >> > > > >-- > -- From acling at ee.ualberta.ca Sun Jun 9 14:33:09 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Sun, 9 Jun 2002 12:33:09 -0600 (MDT) Subject: [manticore] Re: OpenCores In-Reply-To: <20020605222948.10AF7898A@ns1.digitaljunkies.ca> Message-ID: Jeff, since when did your project get on Slash dot? It seems like we're getting a lot of interest on this project, Andrew On Wed, 5 Jun 2002 benjcarson at digitaljunkies.ca wrote: > Have you been following/contributing to the discussions on OC? I haven't > really, save for that first post a while ago. I don't see any harm in > starting the project there. We might as well bring it over but maybe > mention that we still have a lot of cleaning up to do. (Probably be good to > say that we're students so that when people see some of the kludge in > vga_fifo_ctrl they understand...) > > Benj > From acling at ee.ualberta.ca Sun Jun 9 14:28:20 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Sun, 9 Jun 2002 12:28:20 -0600 (MDT) Subject: [manticore] Update In-Reply-To: <1023082457.1094.17.camel@lucid> Message-ID: sorry guys, I'm starting on data passer today... Andrew On 2 Jun 2002, Jeff Mrochuk wrote: > Alright, now that I'm all moved in, and we probably have some new > subscribers, I'll post an update. > > I've been working on increasing the efficiency of the SDRAM controller, > which is going well but I have yet to do any extensive testing. > > Benj is going to increase the flexibility of the display unit to support > multiple resolutions. > > Haven't heard from andrew in a while. Once you're done with that > triangle thing, maybe you can take a look at textures, or whatever you > think would be interesting. > > The biggest load of work is going to be rewriting vga_fifo_ctrl to > support our new sdram controller and display unit. > > A few people have emailed me saying they subscribed to the list and > haven't seen much activity, likely because we don't have a lot of > developers, and plenty to keep us busy. > > Either way this is a relaxed list, and you can feel free to post > suggestions even if you aren't working on it. Of course we're still > really filling in the base of the project before we add a lot of > features. > > Man, what a boring post. > > Jeff > > > From acling at ee.ualberta.ca Sun Jun 9 14:29:55 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Sun, 9 Jun 2002 12:29:55 -0600 (MDT) Subject: [manticore] Re: FIFO In-Reply-To: <20020605222357.5C771898A@ns1.digitaljunkies.ca> Message-ID: how are you guys testing the stuff, are you loading it onto the board or what?? Andrew On Wed, 5 Jun 2002 benjcarson at digitaljunkies.ca wrote: > > Benj, any signal feature requests, say 3/4 full or something? > > Right now it has a full and empty signal, synch clear, asynch reset. > > > > 1/2 full? I think we might use that somewhere and perhaps a level signal > (that basically reports the difference between the read & write "pointers"). > That one might be slightly tricky to implement generically and to optimize. > Actually, you could just use an up/down counter that is wide enough to > register the depth of the fifo... What do you think? > > Benj > From acling at ee.ualberta.ca Sun Jun 9 15:00:55 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Sun, 9 Jun 2002 13:00:55 -0600 (MDT) Subject: data sender Message-ID: Jeff, so let me get the specs right, all you need is to send 3 pts... here's the idea I have pts in text file: 123.45, 345.00, 245.324 324, 3576.23456, 100000.00 etc... if there is overflow in the number or decimal part, I'll simply truncate the value... how's that sound, for now, i'll have my software mindlessly send data, but, we'll need flow control... how many points should I dump to you guys at a time, Andrew From mrochuk at ee.ualberta.ca Mon Jun 10 09:37:07 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 10 Jun 2002 07:37:07 -0600 Subject: [manticore] data sender In-Reply-To: References: Message-ID: <1023716227.6131.4.camel@lucid> Probably be best to send it groups of three, because that makes up one triangle. Benj, the raster can take the points in any order now, right? So we can just throw the triangles into a FIFO. I have the board here, but its been a while since I've tested anything on the actual hardware. I have to redo the pinouts, because I can't seem to overwrite the pinout file and have it stick. I'll probably do that today. Jeff On Sun, 2002-06-09 at 13:00, Ling Andrew Chaang wrote: > Jeff, > > so let me get the specs right, > > all you need is to send 3 pts... > > here's the idea I have > > pts in text file: > > 123.45, 345.00, 245.324 > 324, 3576.23456, 100000.00 > etc... > > if there is overflow in the number or decimal part, I'll simply truncate > the value... > > how's that sound, > > for now, i'll have my software mindlessly send data, but, we'll need > flow control... > > how many points should I dump to you guys at a time, > > Andrew > > From benjcarson at digitaljunkies.ca Mon Jun 10 10:40:52 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Mon, 10 Jun 2002 08:40:52 -0600 Subject: data sender In-Reply-To: <1023716227.6131.4.camel@lucid> References: <1023716227.6131.4.camel@lucid> Message-ID: <20020610144052.96BDA8961@ns1.digitaljunkies.ca> > Benj, the raster can take the points in any order now, right? So we can > just throw the triangles into a FIFO. We never got that working perfectly, if I recall correctly... We needed to examine each case... Using the data sender might be an easy way of doing so, however. > > I have the board here, but its been a while since I've tested anything > on the actual hardware. I have to redo the pinouts, because I can't > seem to overwrite the pinout file and have it stick. I'll probably do > that today. Bummer. Benj > On Sun, 2002-06-09 at 13:00, Ling Andrew Chaang wrote: >> Jeff, >> >> so let me get the specs right, >> >> all you need is to send 3 pts... >> >> here's the idea I have >> >> pts in text file: >> >> 123.45, 345.00, 245.324 >> 324, 3576.23456, 100000.00 >> etc... >> >> if there is overflow in the number or decimal part, I'll simply truncate >> the value... >> >> how's that sound, >> >> for now, i'll have my software mindlessly send data, but, we'll need >> flow control... >> >> how many points should I dump to you guys at a time, >> >> Andrew >> >> > From jmrochuk at ieee.org Mon Jun 10 11:54:15 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Mon, 10 Jun 2002 09:54:15 -0600 Subject: [manticore] Re: data sender In-Reply-To: <20020610144052.96BDA8961@ns1.digitaljunkies.ca> References: <1023716227.6131.4.camel@lucid> <20020610144052.96BDA8961@ns1.digitaljunkies.ca> Message-ID: <20020610155415.GA11480@lucid.digitaljunkies.ca> > > Bummer. > Totally. -- From jmrochuk at ualberta.ca Tue Jun 11 13:31:31 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Tue, 11 Jun 2002 05:31:31 -1200 Subject: hardware Message-ID: <001001c2116d$fdd5a620$0f4e4618@jeff> Well its been a while but I got the most recent source of Manticore running on the hardware. It even works with my semi parameterized SDRAM controller. Not I'm going to try and replace the altera fifos with my own, and pray. Benj, this was the first time I'd seen our 2am 4 triangles via switches code. Pretty funny. It looks like my new sdram code might have a bug somewhere, its fuzzier than with the old code. I'll take a look. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmrochuk at ualberta.ca Tue Jun 11 13:38:21 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Tue, 11 Jun 2002 05:38:21 -1200 Subject: SDRAM Control Message-ID: <000c01c2116e$c79b3e70$0f4e4618@jeff> sdram_control.vhd is OBSOLETE Not that anyone would dare look at that code anyway. use sdram_control_param.vhd instead, the newest CVS does, you should too. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmrochuk at ieee.org Tue Jun 11 16:58:01 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Tue, 11 Jun 2002 14:58:01 -0600 Subject: CVS Message-ID: <20020611205801.GA13293@lucid.digitaljunkies.ca> I've broken the CVS! It should be fixed tonight. I think I found a bug in vga_fifo_ctrl (or at least one of them) that may have been causing our unstable blanking. I might also clear out the thousands of commented out lines in that giant file. Jeff -- From mrochuk at ee.ualberta.ca Wed Jun 12 03:05:42 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 12 Jun 2002 01:05:42 -0600 Subject: CVS Message-ID: <1023865542.625.3.camel@lucid> CVS is fixed, and almost working with the 4 triangles. Benj, if you're interesting in looking at the raster code, the triangle that is in the top right (in frame_buffer_test) is the case that is broken. Its either red or pink, I think. Jeff From acling at ee.ualberta.ca Wed Jun 12 12:07:53 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Wed, 12 Jun 2002 10:07:53 -0600 (MDT) Subject: [manticore] CVS In-Reply-To: <1023865542.625.3.camel@lucid> Message-ID: hey guys, how do you want the data? right now, you input points in a text file, and it sends those points in groups of three, ideally, do you want them to be stored in a Register for you to grab? 3 points * 16 bits per point = 48bit register... how's that sound? Andrew On 12 Jun 2002, Jeff Mrochuk wrote: > CVS is fixed, and almost working with the 4 triangles. > > Benj, if you're interesting in looking at the raster code, the triangle > that is in the top right (in frame_buffer_test) is the case that is > broken. Its either red or pink, I think. > > Jeff > > > From jmrochuk at ieee.org Wed Jun 12 12:34:54 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Wed, 12 Jun 2002 10:34:54 -0600 Subject: [manticore] CVS In-Reply-To: References: <1023865542.625.3.camel@lucid> Message-ID: <20020612163454.GA9423@lucid.digitaljunkies.ca> Add an 8-bit color for that. So it'd be 16x3 + 8 bits. It'd be best to throw it in a fifo of some kind, so you can store several, and in order, just use a single clock lpm_fifo. So it'd be 56x(however many triangles). 10 or so is good enough for testing purposes. Jeff On Wed, Jun 12, 2002 at 10:07:53AM -0600, Ling Andrew Chaang wrote: > hey guys, > > how do you want the data? > > right now, you input points in a text file, and it sends those points in > groups of three, > > ideally, do you want them to be stored in a Register for you to grab? > > 3 points * 16 bits per point = 48bit register... > > how's that sound? > > Andrew > > On 12 Jun 2002, Jeff Mrochuk wrote: > > > CVS is fixed, and almost working with the 4 triangles. > > > > Benj, if you're interesting in looking at the raster code, the triangle > > that is in the top right (in frame_buffer_test) is the case that is > > broken. Its either red or pink, I think. > > > > Jeff > > > > > > > -- From jmrochuk at ieee.org Fri Jun 14 12:36:13 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Fri, 14 Jun 2002 10:36:13 -0600 Subject: DACs Message-ID: <20020614163613.GA308@lucid.digitaljunkies.ca> Where did the jpeg guys get their DAC? I'd like to email a few people for samples. Jeff -- From benjcarson at digitaljunkies.ca Fri Jun 14 12:49:48 2002 From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca) Date: Fri, 14 Jun 2002 10:49:48 -0600 Subject: DACs In-Reply-To: <20020614163613.GA308@lucid.digitaljunkies.ca> References: <20020614163613.GA308@lucid.digitaljunkies.ca> Message-ID: <20020614164948.A82708961@ns1.digitaljunkies.ca> They got them from Analog Devices. That RAMDAC I was looking at earlier came from them too. Their web page is http://www.analog.com and info about ordering samples directly from their site is at http://www.analog.com/productSelection/orderSamples/index.html. Benj Jeff Mrochuk writes: > Where did the jpeg guys get their DAC? I'd like to email a few people > for samples. > > Jeff > -- From michland at michland.tk Mon Jun 17 09:25:29 2002 From: michland at michland.tk (michland) Date: Mon, 17 Jun 2002 17:25:29 +0400 Subject: Manticore Message-ID: <10416358875.20020617172529@michland.tk> Hi ALL! I'm intrested in Manticore project. I've got CVS snapshot and found it attractive. Q: Do you plan develop support OpenGL (or DirectX) API? Q: Why do you not think about DVI in/out (is it more complicated?)? Q: What's about vendor-specific (Altera) version of Manticore (you're using Altera's evaluation board, am I right?). -- Digitally yours, michland mailto:michland at michland.tk From mrochuk at ee.ualberta.ca Mon Jun 17 09:52:25 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 17 Jun 2002 07:52:25 -0600 Subject: [manticore] Manticore In-Reply-To: <10416358875.20020617172529@michland.tk> References: <10416358875.20020617172529@michland.tk> Message-ID: <1024321945.6072.1.camel@lucid> > Q: Do you plan develop support OpenGL (or DirectX) API? > Yes, but its a ways down the road. Since this is an open project, we'll likely go for OpenGL first, since it is multiplatform. > Q: Why do you not think about DVI in/out (is it more complicated?)? > Haven't looked into it. > Q: What's about vendor-specific (Altera) version of Manticore (you're > using Altera's evaluation board, am I right?). > I'm in the process of getting rid of all Altera specific code, but it may be quite a lot of work. Jeff From michland at michland.tk Mon Jun 17 11:22:42 2002 From: michland at michland.tk (michland) Date: Mon, 17 Jun 2002 19:22:42 +0400 Subject: [manticore] Manticore In-Reply-To: <1024321945.6072.1.camel@lucid> References: <10416358875.20020617172529@michland.tk> <1024321945.6072.1.camel@lucid> Message-ID: <266729375.20020617192242@michland.tk> Hi Jeff, Monday, June 17, 2002, 5:52:25 PM, you wrote: >> Q: What's about vendor-specific (Altera) version of Manticore (you're >> using Altera's evaluation board, am I right?). >> JM> I'm in the process of getting rid of all Altera specific code, but it JM> may be quite a lot of work. I have an ability to work with Altera's APEX devices. What software did you use for compilation (Quartus, MAX+, which version?)? -- Digitally yours, michland mailto:michland at michland.tk From jmrochuk at ieee.org Mon Jun 17 11:21:53 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Mon, 17 Jun 2002 09:21:53 -0600 Subject: [manticore] Manticore In-Reply-To: <266729375.20020617192242@michland.tk> References: <10416358875.20020617172529@michland.tk> <1024321945.6072.1.camel@lucid> <266729375.20020617192242@michland.tk> Message-ID: <20020617152153.GA7085@lucid.digitaljunkies.ca> We're using (unfortunately, sometimes) Quartus II v1.1 Jeff On Mon, Jun 17, 2002 at 07:22:42PM +0400, michland wrote: > Hi Jeff, > > Monday, June 17, 2002, 5:52:25 PM, you wrote: > > > >> Q: What's about vendor-specific (Altera) version of Manticore (you're > >> using Altera's evaluation board, am I right?). > >> > > JM> I'm in the process of getting rid of all Altera specific code, but it > JM> may be quite a lot of work. > > I have an ability to work with Altera's APEX devices. What software > did you use for compilation (Quartus, MAX+, which version?)? > > > > -- > Digitally yours, > michland mailto:michland at michland.tk > -- From michland at michland.tk Mon Jun 17 11:42:56 2002 From: michland at michland.tk (michland) Date: Mon, 17 Jun 2002 19:42:56 +0400 Subject: [manticore] Manticore In-Reply-To: <20020617152153.GA7085@lucid.digitaljunkies.ca> References: <10416358875.20020617172529@michland.tk> <1024321945.6072.1.camel@lucid> <266729375.20020617192242@michland.tk> <20020617152153.GA7085@lucid.digitaljunkies.ca> Message-ID: <1337942796.20020617194256@michland.tk> Hi Jeff, JM> We're using (unfortunately, sometimes) Quartus II v1.1 QuartusII v2.0 sp2 produces internal error while compile vgaout.vhd :( I'm trying explore problem... -- Digitally yours, michland mailto:michland at michland.tk From jmrochuk at ieee.org Mon Jun 17 12:37:45 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Mon, 17 Jun 2002 10:37:45 -0600 Subject: [manticore] Manticore In-Reply-To: <1337942796.20020617194256@michland.tk> References: <10416358875.20020617172529@michland.tk> <1024321945.6072.1.camel@lucid> <266729375.20020617192242@michland.tk> <20020617152153.GA7085@lucid.digitaljunkies.ca> <1337942796.20020617194256@michland.tk> Message-ID: <20020617163745.GA7782@lucid.digitaljunkies.ca> I've compiled in on the QuartusII 2.0 web edition, and it was okay, but not service pack 2. Jeff On Mon, Jun 17, 2002 at 07:42:56PM +0400, michland wrote: > Hi Jeff, > > > JM> We're using (unfortunately, sometimes) Quartus II v1.1 > > QuartusII v2.0 sp2 produces internal error while compile > vgaout.vhd :( > > I'm trying explore problem... > > > > -- > Digitally yours, > michland mailto:michland at michland.tk > -- From manido at ece.uci.edu Mon Jun 17 15:08:01 2002 From: manido at ece.uci.edu (Manuel L. Anido) Date: Mon, 17 Jun 2002 12:08:01 -0700 Subject: Read: [manticore] Manticore References: <10416358875.20020617172529@michland.tk> Message-ID: <003201c21632$4d069c90$1509c880@ANIDO> This is a receipt for the mail you sent to at 6/17/2002 6:25 AM This receipt verifies that the message has been displayed on the recipient's computer at 6/17/2002 12:08 PM From jmrochuk at ualberta.ca Tue Jun 18 11:37:15 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Tue, 18 Jun 2002 03:37:15 -1200 Subject: Sweet Sweet Progress Message-ID: <001101c216de$05fa8490$0f4e4618@jeff> Finally made some progress today. All the triangle drawing has stable images (although not perfect) Turns out read_line_warn is broken, but I'm not sure why, but it also works fine without it. I know have the tb_Buffer_ready hooked up to a button so I can draw each of the 4 triangles at my will. There's two broken cases, (they say trouble beside them in the code). Looking into it more this evening. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason_watkins at pobox.com Tue Jun 18 02:49:31 2002 From: jason_watkins at pobox.com (Jason Watkins) Date: Mon, 17 Jun 2002 23:49:31 -0700 Subject: 3d graphics multiprocessor Message-ID: <007e01c21694$4d5d0d70$426f2a40@boondock> Apologies if this is considered off topic, there are few communities around that deal with gfx hardware design. I've been wondering for a while why someone doesn't develop a graphics chip based on a multiprocessor design. Take an appropriate memory architecture, a decent performance IEEE single precision core, and stir in the rest of the DAC, bus control, etc you'd need. The concept being that for a small R&D effort, spending time on an instanced ALU and implimenting algorithms in software where they are easily revised without hardware costs would be a winning strategy. I've found some work on this from the stream multiprocessor crowd, however, their memory architecture handles random access to small working sets poorly, something that is *very* nessisary for good fill rate from texture mapping. I don't think there's any real reason a stream like architecture could be combined with appropriate caches. So I was wondering if any of you had thought along these lines, knew of work along these lines, or immediately know why it is an approach doomed to failure. jason watkins From jmrochuk at ieee.org Tue Jun 18 11:42:39 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Tue, 18 Jun 2002 09:42:39 -0600 Subject: Brilliant. Message-ID: <20020618154239.GA6928@lucid.digitaljunkies.ca> Well, I think I've figured out why our blanking technique was only getting chunks of data, instead of a smooth row at a time. The write fifo is using Byte masking to draw the triangle, so certain bytes (where the triangle isn't) aren't overwritten. Now when you go back to vga_fifo_ctrl the data mask needs to be reset, which it is, so that the entire words are written. The problem with setting the byte masks back to 0 in vga_fifo_ctrl is simple. The data mask in vga_fifo_ctrl is not connected to anything. I'll fix that. -Jeff -- From jmrochuk at ieee.org Tue Jun 18 11:50:53 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Tue, 18 Jun 2002 09:50:53 -0600 Subject: [manticore] Brilliant.\ In-Reply-To: <20020618154239.GA6928@lucid.digitaljunkies.ca> References: <20020618154239.GA6928@lucid.digitaljunkies.ca> Message-ID: <20020618155053.GA7097@lucid.digitaljunkies.ca> vga_fifo_ctrl doesn't need control over blanking at all, it'd just add another uneccessary tri-state. Instead the write_fifo_ctrl will just reset the mask to 0 when not writing. Jeff On Tue, Jun 18, 2002 at 09:42:39AM -0600, Jeff Mrochuk wrote: > Well, I think I've figured out why our blanking technique was only > getting chunks of data, instead of a smooth row at a time. > > The write fifo is using Byte masking to draw the triangle, so certain > bytes (where the triangle isn't) aren't overwritten. > > Now when you go back to vga_fifo_ctrl the data mask needs to be reset, > which it is, so that the entire words are written. The problem with > setting the byte masks back to 0 in vga_fifo_ctrl is simple. > > The data mask in vga_fifo_ctrl is not connected to anything. > > I'll fix that. > > -Jeff > -- -- From mrochuk at ee.ualberta.ca Tue Jun 18 19:18:39 2002 From: mrochuk at ee.ualberta.ca (Jeff Mrochuk) Date: 18 Jun 2002 17:18:39 -0600 Subject: [manticore] 3d graphics multiprocessor In-Reply-To: <007e01c21694$4d5d0d70$426f2a40@boondock> References: <007e01c21694$4d5d0d70$426f2a40@boondock> Message-ID: <1024442319.607.2.camel@lucid> I've actually had someone recommend we try using a RISC processor for vertex operations (all the floating point stuff) and I think its quite a good idea. Memory on the other hand in our system is handled entirely parallel to everything else. Fill rate (like you said) is really important, so we have our own memory controller which is running all the time, unlike say a microprocessor which does things sequentially. Basically adding a microprocessor for math and other tasks would be helpful if the clock was fast enough to keep ahead of the rendering core. Something to look at. -Jeff On Tue, 2002-06-18 at 00:49, Jason Watkins wrote: > Apologies if this is considered off topic, there are few communities around > that deal with gfx hardware design. > > I've been wondering for a while why someone doesn't develop a graphics chip > based on a multiprocessor design. Take an appropriate memory architecture, a > decent performance IEEE single precision core, and stir in the rest of the > DAC, bus control, etc you'd need. > > The concept being that for a small R&D effort, spending time on an instanced > ALU and implimenting algorithms in software where they are easily revised > without hardware costs would be a winning strategy. > > I've found some work on this from the stream multiprocessor crowd, however, > their memory architecture handles random access to small working sets > poorly, something that is *very* nessisary for good fill rate from texture > mapping. I don't think there's any real reason a stream like architecture > could be combined with appropriate caches. > > So I was wondering if any of you had thought along these lines, knew of work > along these lines, or immediately know why it is an approach doomed to > failure. > > jason watkins > > > From jmrochuk at ualberta.ca Wed Jun 19 08:21:02 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Wed, 19 Jun 2002 00:21:02 -1200 Subject: Quartus II Message-ID: <000e01c2178b$c6f2f760$0f4e4618@jeff> Quartus II has destroyed all of its own configuration files (likely due to the fact it doesn't shut down properly) I think I have to redo the pinouts again. Installing some service packs. This better not happen again. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From whygee at f-cpu.org Tue Jun 18 20:38:59 2002 From: whygee at f-cpu.org (Yann Guidon) Date: Wed, 19 Jun 2002 02:38:59 +0200 Subject: [manticore] 3d graphics multiprocessor References: <007e01c21694$4d5d0d70$426f2a40@boondock> <1024442319.607.2.camel@lucid> Message-ID: <3D0FD2A3.694C544B@f-cpu.org> hello, Jeff Mrochuk wrote: > > I've actually had someone recommend we try using a RISC processor for > vertex operations (all the floating point stuff) and I think its quite a > good idea. > > Memory on the other hand in our system is handled entirely parallel to > everything else. Fill rate (like you said) is really important, so we > have our own memory controller which is running all the time, unlike say > a microprocessor which does things sequentially. > > Basically adding a microprocessor for math and other tasks would be > helpful if the clock was fast enough to keep ahead of the rendering > core. > > Something to look at. F-CPU is a SIMD superpipelined microprocessor code that we're designing. I have no idea how to integrate it with Manticore but it is designed to have a lot of horsepower. Here is a little example of the code, http://www.f-cpu.seul.org/whygee/dct_fc0/dct_fc0.html and i am preparing new papers. Just explore http://www.f-cpu.seul.org/ to see what we've done so far (VHDL at http://www.f-cpu.seul.org/new/ for example). You can also find there the lastest versions of the manual (which lags a lot, but has some useful informations). Just in case you don't know, F-CPU is a "64-bit minimum" machine so it can handle large SIMD words in the future. With its 64 orthogonal registers, it's adapted to heavy loads. One of the remarks i have about Manticore is that AFAIK there is no support for "blitting", doing ROP2 operations on screen tiles (moving one screen block to another, maybe hidden, and apply a boolean operation on the result). While F-CPU is designed to do that (and much more) happily, it's a big overkill... However, sending vertices to the 3D engine's FIFO is straightforward, using the Special Register's interface ("put" and "get" instructions to an independent, synchronous addressing space). i'd be happy to learn more about Manticore and discuss with you. > -Jeff WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From jason_watkins at pobox.com Wed Jun 19 02:41:23 2002 From: jason_watkins at pobox.com (Jason Watkins) Date: Tue, 18 Jun 2002 23:41:23 -0700 Subject: [manticore] 3d graphics multiprocessor References: <007e01c21694$4d5d0d70$426f2a40@boondock> <1024442319.607.2.camel@lucid> Message-ID: <00ab01c2175c$54559480$426f2a40@boondock> Yes, adding a conventional embeded processor for vertex workloads has been done many times, it works. I think the first one I heard of was Intergraph putting Alpha's on their high end board set. Pretty funny that the embeded cpu in such systems was faster than the host machine's x86. I definately think this could be a good way for manticore to get functionality and decent performance quickly. What I'm thinking of goes a bit farther than that. What I'm talking about is doing away with the conventional pipeline, and reimplimenting it in parellel code for a multi-processor (multiple cores on one die). http://citeseer.nj.nec.com/owens00polygon.html is probibly the closest thing I've found in literature, and as far as vertex workloads, is shown to have great performance and staggering aggregate register bandwidth. However, it's stream based memory model forces a large seperation between operand registers and memory, so fill rate for zbuffering or texture mapping is less than impressive. I also think their particular software implimentation could be substancially improved. What I'm thinking of more is a set cores with a collection of common fifo's, a reasonable size cache, and a programable prefetch unit. The simplist programing model is of a single computational kernel that is vectored accross the fpu's. Temporary results like transformed vertexes, set-up triangles, scan converted spans or blocks would be stored and consumed from fifo's. I'm envisioning blocks would be guarded by fifo status, so that a full fifo stalls the section of the kernel that fills it until another block of the kernel consumes an element, rather than attempting to page streams to main memory. I imagine a partitioned register file to support the single kernel programming model while relaxing the number of ports required, and a TTL instruction set for simplicity. Finally, there would be a similarly partitioned cache, suitable for holding blocks of texture, z and other such buffers. Each core need not be particularly super-scalar, tho 2-way would probibly be an advantage. A IEEE 32bit fpu design would suffice, ideally with some vector extensions for operations on wide and byte sized values to substancially speed shading operations and packing/unpacking. What's the point of all this? Although current hardware is amazingly fast, even with current shader standards the functionality is very fixed. Current polygon rates result in densities nearing 8 pixel triangles. Given another cycle or 2, the very idea of a polygon will start to lose it's advantages. Everyone seems to think the way to solve these trends is to reinvent RIB as a realtime format. While I don't disagree that a renderman like format for realtime input would be a step forward, I still think it falls short. Why not truely free the pipeline by adopting a fully programable system, rather than programamble islands in a fixed data flow? Remember the days when all games rendered in software? There was huge variety of algorithms since each game was free to organize what computation was available in a way most ideal for their situation. Think of all the computer vision, signal processing, analysis and visualization workloads that would benfit from such a chip being available. There are a staggering number of interesting algorithms in the literature that while definately appealing for particular situations, are incompatable with current hardware, limiting them to exercises in theory. Worse yet, there are even far more that would be easily realizable with a single limited addition to the pipeline, but it would be increasingly complex to attempt to add more than a single extention. What I want is a chip designed to run programs that fit their bandwidth pattern, and that doesn't have the overhead that comes from the full generality and ILP extration that system cpu's burden. I want a media processor. The graphix card is really the only place such a chip might gain a foothold. And it might be a good way for a small hobby group to transform as much of a hardware problem as they can into a software problem with enough geek appeal to muster a sizable open source effort. But in the end, it's just a daydream, and I have the feeling that it seems so appealing as a paper tiger that there must be some flaw, some reason no one has explored it before. So that's why I'm hoping you guys can punch holes in it to save me from spending more and more time considering it :P jason watkins From acling at ee.ualberta.ca Wed Jun 19 23:22:22 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Wed, 19 Jun 2002 21:22:22 -0600 (MDT) Subject: Decimal numbers Message-ID: Jeff or Benj, For debugging purposes, we're representing decimal numbers with a 10 bit integer part and 6 bit decimal part... The integer part is obvious in translating to binary, as for the decimal part, how do you want it represented... for example, how do you want 0.345 translated into a 6-bit number thanks, Andrew From jmrochuk at ualberta.ca Thu Jun 20 11:39:59 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Thu, 20 Jun 2002 03:39:59 -1200 Subject: [manticore] Decimal numbers References: Message-ID: <001b01c21870$bc86cd70$0f4e4618@jeff> We're using regulary binary fractions ie 1/2(0.5) => 0.1 1/4(0.25) => 0.01 1/8(0.125) => 0.001 1/16(0.0625) => 0.0001 1/32(0.03125) => 0.00001 1/64(0.015625) => 0.000001 so 0.345 would be 0.01011 or so ----- Original Message ----- From: "Ling Andrew Chaang" To: Sent: Wednesday, June 19, 2002 3:22 PM Subject: [manticore] Decimal numbers > Jeff or Benj, > > For debugging purposes, > > we're representing decimal numbers with a 10 bit integer part and 6 bit > decimal part... > > The integer part is obvious in translating to binary, as for the decimal > part, how do you want it represented... > > for example, how do you want 0.345 translated into a 6-bit number > > thanks, > Andrew > > From jmrochuk at ualberta.ca Thu Jun 20 11:46:07 2002 From: jmrochuk at ualberta.ca (Jeff Mrochuk) Date: Thu, 20 Jun 2002 03:46:07 -1200 Subject: [manticore] Decimal numbers References: <001b01c21870$bc86cd70$0f4e4618@jeff> Message-ID: <003001c21871$98625f30$0f4e4618@jeff> Also the top bit of the integer part is a sign bit. So the MSB of the whole 16 bit number is sign ----- Original Message ----- From: "Jeff Mrochuk" To: Sent: Thursday, June 20, 2002 3:39 AM Subject: Re: [manticore] Decimal numbers > We're using regulary binary fractions > > ie 1/2(0.5) => 0.1 > 1/4(0.25) => 0.01 > 1/8(0.125) => 0.001 > 1/16(0.0625) => 0.0001 > 1/32(0.03125) => 0.00001 > 1/64(0.015625) => 0.000001 > so 0.345 would be 0.01011 or so > > > > ----- Original Message ----- > From: "Ling Andrew Chaang" > To: > Sent: Wednesday, June 19, 2002 3:22 PM > Subject: [manticore] Decimal numbers > > > > Jeff or Benj, > > > > For debugging purposes, > > > > we're representing decimal numbers with a 10 bit integer part and 6 bit > > decimal part... > > > > The integer part is obvious in translating to binary, as for the decimal > > part, how do you want it represented... > > > > for example, how do you want 0.345 translated into a 6-bit number > > > > thanks, > > Andrew > > > > > From manido at ece.uci.edu Thu Jun 20 12:45:38 2002 From: manido at ece.uci.edu (Manuel L. Anido) Date: Thu, 20 Jun 2002 09:45:38 -0700 Subject: Unsubscribe information Message-ID: <031c01c21879$e8c306c0$1509c880@ANIDO> Hi guys, Could you please tell me how to unsubscribe the mailing list. Many thanks. Manuel L. Anido -------------- next part -------------- An HTML attachment was scrubbed... URL: From acling at ee.ualberta.ca Thu Jun 20 12:36:27 2002 From: acling at ee.ualberta.ca (Ling Andrew Chaang) Date: Thu, 20 Jun 2002 10:36:27 -0600 (MDT) Subject: [manticore] Unsubscribe information In-Reply-To: <031c01c21879$e8c306c0$1509c880@ANIDO> Message-ID: this should answer your questions... --- original message I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: For help and a description of available commands, send a message to: To subscribe to the list, send a message to: To remove your address from the list, just send a message to the address in the ``List-Unsubscribe'' header of any list message. If you haven't changed addresses since subscribing, you can also send a message to: cheers, Andrew On Thu, 20 Jun 2002, Manuel L. Anido wrote: > Hi guys, > > Could you please tell me how to unsubscribe the mailing list. > > Many thanks. > > Manuel L. Anido > > From icculus at clutteredmind.org Thu Jun 20 22:06:18 2002 From: icculus at clutteredmind.org (Ryan C. Gordon) Date: Thu, 20 Jun 2002 22:06:18 -0400 (EDT) Subject: [manticore] Unsubscribe information In-Reply-To: <031c01c21879$e8c306c0$1509c880@ANIDO> Message-ID: > Could you please tell me how to unsubscribe the mailing list. Send a blank mail to manticore-unsubscribe at icculus.org ... if this doesn't work for some reason, email me directly and I'll remove you. --ryan. From jmrochuk at ieee.org Tue Jun 25 14:14:24 2002 From: jmrochuk at ieee.org (Jeff Mrochuk) Date: Tue, 25 Jun 2002 12:14:24 -0600 Subject: Slow Message-ID: <20020625181424.GA14622@lucid.digitaljunkies.ca> I'm not doing much on the code base this week... vacation Jeff --