From kenneo at langly.org Wed Mar 4 04:31:58 2009 From: kenneo at langly.org (Kenneth Ostby) Date: Wed Mar 4 00:33:53 2009 Subject: [Open-graphics] Pipelining - 3D Engine Message-ID: <20090304093158.GB18521@li11-44.members.linode.com> In the series on architectural / performance rants. The last week I committed some basic verilog skeleton files which marks the beginning of the rasterization module of the 3D engine. However, it was one problem which struck me with the implementation of the logic itself, namely how to solve pipeline stalls. A good example would be in the horizontal rasterizer[1], where you can see that I have divided it up into 3 basic stages, corresponding to the calculations found in the new_model code. Basically: 1) adjustment = some math 2) initial point = more math * adjustment 3) for each step in width: calculate values for step. Now, the two first stages are easy, the cycle count from the entry of data into stage 1 until it's ready for output in stage 2 is fixed, and mainly depends on the latency introduced by the floating point operations involved. However, the problem comes with stage 3. Since stage 3 logically involves a loop over the width, it might have to stall the pipeline while waiting for the while loop to finish processing. Thus the question arise, what are we going to do with the data already introduced into the pipeline? The naive solution to the problem/challenge is to introduce a queue at the end of each stage. This means that the depth of the queue has to be at least the same number as the cycles used by the stage itself. This is explained by the case where we have filled the entire pipeline of the floating point module and we encounter a pipeline stall. In that case we have to be able to store all of the output generated by the floating points modules, since the FP modules have no mechanisms for stalling themselves. Then the stage has to stall, not being able to accept any data, nor processing anything until the stall ends. My major problem with this solution is that it, as far as I can see, in the case of a stall will introduce a latency in terms of startup costs. If the queues are full, and if we encounter a stall from the next step in the pipeline we cannot accept new incoming data either, since we cannot guarantee that we will have space in the outgoing queue for the results. Hence we will have a startup cost in terms of cycles equal to the cycle count data uses through the pipeline step. Anybody have some good solutions? The easy answer is to say that it doesn't cost that much compared to feature Y, but it feels a bit like cheating. Other solution is to, in every pipeline step, incorporate a "store/do not continue" flag and store the output in a register local to the step. If you read through this entire mail, Thank you for your attention :) Regards, Kenneth [1] http://langly.org/og/rastHori.png -- Life on the earth might be expensive, but it includes an annual free trip around the sun. Kenneth ?stby http://langly.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.duskglow.com/open-graphics/attachments/20090304/4d1ec710/attachment.bin From theosib at gmail.com Wed Mar 4 12:50:43 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Wed Mar 4 08:52:39 2009 Subject: [Open-graphics] Pipelining - 3D Engine In-Reply-To: <20090304093158.GB18521@li11-44.members.linode.com> References: <20090304093158.GB18521@li11-44.members.linode.com> Message-ID: <9871ee5f0903040950u52325789x8ee096b5eb85edc9@mail.gmail.com> Some number of ages ago, I posted some things to the list where I described how to handle all of this. We'll have to dig it out of the archive. And some of this may have ended up on the wiki, but I'm not sure. In short, I described a method for merging the pipeline segment (a segment being a set of stages) with the fifo such that (a) the pipeline can't 'overfill' and lose anything, (b) 'packs' bubbles, meaning that earlier stages can progress even when later stages are busy as long as there are bubbles in the pipeline, and (c) prevents the busy signal handling from becoming a critical path (with some careful planning). I described generic modules called "HEADER", "FOOTER", and two others that can perform processing, one that is a simple pipeline stage, and the other that can communicate with external logic (such as reading/writing a FIFO). Each pipeline stage has a 'busy' or 'valid' bit that indicates that something is IN that pipeline stage. It means that the next stage should accept output (if it can), or if it can't, it means that earlier stages must wait. The last stage of a segment pays attention only to the busy input from the next segment (unless it performs some multi-step process), the second-to-last stage pays attention to the busy input and the valid status of the last stage. As you move backward, the number of inputs to for a stage to determine whether or not to do something grows, and eventually reaches a point where it can become a critical path. At that point, you break the pipeline into another segment. The FOOTER's job is basically just to interpret the signals from a subsequent segment. The HEADER's job is to break the combinatorial path between all of the busy signals in one segment and those in another by making the segment's busy signal registered. To do this, it acts as a queue that can hold 0 or 1 entries, multiplexing between either the input from the previous segment (if this segment is not busy) or a registered copy of an earlier input (if the segment is busy and therefore holding something). Due to the multiplexing, you typically want to put a DUMMY stage after a HEADER. All it does is remove the multiplexing from the critical paths. The nice thing about HEADER and FOOTER stages is that they "speak fifo language", which means that it is trivial to bolt a fifo onto the end of a pipeline segment, because a pipeline segment looks just like a fifo. It has exactly the same sorts of external control signals. I provided source code to all of this. We'll have to dig it out. So far, I haven't been able to get Google to find it. A stage that performs a multi-step process (like what we'll have to do with textures in certain modes) will basically function as a pipeline segment all its own, managing a registered busy signal for prior stages, and that busy signal will be a combination of stage machine states and busy signals from subsequent stages. On 3/4/09, Kenneth Ostby wrote: > In the series on architectural / performance rants. > > The last week I committed some basic verilog skeleton files which marks > the beginning of the rasterization module of the 3D engine. However, it > was one problem which struck me with the implementation of the logic > itself, namely how to solve pipeline stalls. A good example would be in > the horizontal rasterizer[1], where you can see that I have divided it > up into 3 basic stages, corresponding to the calculations found in the > new_model code. Basically: > > 1) adjustment = some math > 2) initial point = more math * adjustment > 3) for each step in width: > calculate values for step. > > Now, the two first stages are easy, the cycle count from the entry of > data into stage 1 until it's ready for output in stage 2 is fixed, and > mainly depends on the latency introduced by the floating point > operations involved. However, the problem comes with stage 3. Since > stage 3 logically involves a loop over the width, it might have to stall > the pipeline while waiting for the while loop to finish processing. Thus > the question arise, what are we going to do with the data already > introduced into the pipeline? > > The naive solution to the problem/challenge is to introduce a queue at > the end of each stage. This means that the depth of the queue has to be > at least the same number as the cycles used by the stage itself. This is > explained by the case where we have filled the entire pipeline of the > floating point module and we encounter a pipeline stall. In that case we > have to be able to store all of the output generated by the floating > points modules, since the FP modules have no mechanisms for stalling > themselves. Then the stage has to stall, not being able to accept any > data, nor processing anything until the stall ends. > > My major problem with this solution is that it, as far as I can see, in > the case of a stall will introduce a latency in terms of startup costs. > If the queues are full, and if we encounter a stall from the next step > in the pipeline we cannot accept new incoming data either, since we > cannot guarantee that we will have space in the outgoing queue for the > results. Hence we will have a startup cost in terms of cycles equal to > the cycle count data uses through the pipeline step. > > Anybody have some good solutions? The easy answer is to say that it > doesn't cost that much compared to feature Y, but it feels a bit like > cheating. Other solution is to, in every pipeline step, incorporate a > "store/do not continue" flag and store the output in a register local to > the step. > > If you read through this entire mail, > Thank you for your attention :) > > Regards, > Kenneth > > > [1] http://langly.org/og/rastHori.png > > > > -- > Life on the earth might be expensive, but it > includes an annual free trip around the sun. > > Kenneth ?stby > http://langly.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmuSo0ACgkQpcFZhY+Vljz1VQCghnHoj66iOm9bHzUqGnAWl9zU > AZIAoIEbIcTRIzwU4vY1RTT7dqVzJoFe > =PqGo > -----END PGP SIGNATURE----- > > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From theosib at gmail.com Wed Mar 4 13:08:34 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Wed Mar 4 09:10:28 2009 Subject: [Open-graphics] 3D Engine - Some thoughts In-Reply-To: <20090222212401.GA25766@li11-44.members.linode.com> References: <20090222212401.GA25766@li11-44.members.linode.com> Message-ID: <9871ee5f0903041008o74db97deo2e0917548be6c379@mail.gmail.com> On 2/22/09, Kenneth Ostby wrote: > Heya, > > Recently, I've been looking up and reading through the documentation > available for the 3D Engine[1] part of the project ( It's in need of > some love as well ), and the software model of our rasterizer found in > the SVN repository. This has been in order to try to plan ahead, and > identify the work that has to be done. And in relations to that I have > some questions. > > First, in each of the different stages [2] in the pipeline, Rasterize, > Ownership, etc, we have some that just have to be forwarded for further > use into the pipeline. Texture coordinates and Texture ID is a good > example. Hence, what I'm thinking, is that if we in front of the > Rasterizer / Scissor step in the pipeline, include a issue unit, it > should be possible for the issue unit to bite off the unneeded parts and > just forward it to the correct stage where it's first needed. Then, in > the different stages in the pipeline, we could include a FIFO buffer > where we store the data for future usage. Also, since we're operating on > a strict in-order processor, it shouldn't need to be anything more > complex than a simple FIFO buffer. You seem to be suggesting that we provide an ability to bypass pipeline segments that are not going to be used. This would certainly reduce latency. There are some tradeoffs, however. One is that what is enabled and disabled changes fairly frequently. To enable and disable pipeline stages would require a pipeline flush, introducing a significant delay. As long as we're keeping the pipeline busy, it doesn't really matter what the latency is. Secondly, this introduces the need to add additional mutiplexing and routing around pipeline segments. All reasonable configurations need to be accounted for, which implies crossbars. Those introduce latency of their own, as well as creating routing congestion in the FPGA. We'll get a higher clock frequency if we can make the pipeline streamlined and easy to place and route. > > Also, by doing this, we can try to hide some of the latencies found in > the pipeline in memory reads / writes. As an example, imagine that we > have the case of texture element. In the current model, it would require > that the pipeline stalls while waiting for a texture fetch. If we send > the coordinates ahead, it should be possible to prefetch some of the > needed texels before the fragments gets to the texture stage. I am sure > that this technique can be utilized more places in the pipeline as well. Let's consider something simpler, like the Z buffer. This is straight forward. For each fragment, we need to read a word from memory and possible write one. The write is trivial, since that can be just dumped into a fifo and processed out of order (unless the fifo fills, in which case, we're memory bound, and we don't care about the delay). The read, however, complicates things. The solution involves three fifos. The memory system is already build around fifos. For reads, requests are issued down one pipe, and then the data comes back in another. If you could continue to issue requests asynchronously from processing the data, you could keep the pipeline moving. What we do is insert a third fifo between the pipeline segment that requests the reads and the segment that receives and processes the data. As requests are pushed into the memory fifo, fragments are pushed into another one that only fills up and causes a stall if memory can't keep up with requests. Let's call this third fifo a "latency absorber". For Z, this is quite straightforward. For textures, which may involve multiple requests per fragment, which implies a state machine that will hold up the pipeline. The receiver also must loop over multiple received pixels to fully compute the fragment. I have two possible solutions to this. One is to have two full state machines at each end of the latency absorber. Each has its own set of configuration variables, and we just design them so that they do complementary work. The other alternative is to have one state machine at the head of the queue that also passes commands down the latency absorber which are processed by the receiver. Those commands would be things like "here's a fragment to be processed", "expect a pixel from memory, do this with it to modify the fragment", and "complete processing of the fragment and forward it to the next segment". (Some of those commands may be issued simultaneously, like when the last texel is received, the finish command may just be a flag bit.) Speaking of configuration variables, we would pass those down the pipeline, as if they were fragment data, reusing some of the same signals. When the parameter reaches the segment or stage that holds that variable, it gets stored right there. Thus, the pipeline is not stalled by variable changes. > Secondly, we have a lot of configuration parameters which need to set > for the engine, and which needs to be handled in an efficient manner. > Hence, I'm suggesting that we add some sort of registry file to the > architecture as well. Also by employing this technique, we could later > incorporate some sort of performance counter system, or as a way of > giving feedback from the system. Counters would definitely be useful for debugging. I've already described how to handle register writes. They pass down the pipeline and are stored locally in the stage. For read-backs, which are rare and only used for debugging, we can make them happen out of order. Just a big MUX in the engine routes them all back to PCI. > I tried to modify Tim's original block diagram with Gimp to kinda show > what I was talking about and the result can be found here [3]. Also, I > would like to apologize for breaking the pretty diagram. It seems > like a simple action such as drawing a box or a straight line in gimp is > meant to be hard. > > Kenneth > > [1] http://wiki.opengraphics.org/tiki-index.php?page=OGA%20Engine > [2] http://langly.org/og/block_diagram.gif > [3] http://langly.org/og/block-mod.gif > > > -- > Life on the earth might be expensive, but it > includes an annual free trip around the sun. > > Kenneth ?stby > http://langly.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmhwnAACgkQpcFZhY+VljxoCACfclEmobz6FRpSq0FBkajMK+Bk > mhAAoNSAW4fwAb/6//GjnnbwSKIJyiY0 > =jvMn > -----END PGP SIGNATURE----- > > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From theosib at gmail.com Wed Mar 4 13:31:14 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Wed Mar 4 09:33:09 2009 Subject: [Open-graphics] Pipelining - 3D Engine In-Reply-To: <9871ee5f0903040950u52325789x8ee096b5eb85edc9@mail.gmail.com> References: <20090304093158.GB18521@li11-44.members.linode.com> <9871ee5f0903040950u52325789x8ee096b5eb85edc9@mail.gmail.com> Message-ID: <9871ee5f0903041031v507ef06dj351b652a8f34e3aa@mail.gmail.com> Here's the tutorial on that: http://wiki.opengraphics.org/tiki-index.php?page=TutorialPipelines From john.culp at me.gatech.edu Thu Mar 12 03:20:46 2009 From: john.culp at me.gatech.edu (Culp, John R) Date: Wed Mar 11 23:23:07 2009 Subject: [Open-graphics] TVC Release #4 aka "T-Mapper" Message-ID: <896594299.2435251236842446882.JavaMail.root@mail5.gatech.edu> This release implements hardware texture mapping! Texture mapping is performed at the scanline level. I use 16 bit fixed point math for texture coordinates in the fpga. Textures are the same 256x256 size as demonstrated in Release #3's software demo. I fixed the bug that created the incorrect color distribution and black rectangles in the "Utah Spinner" demo. I had specified the pins on the fpga output lines for the green and blue colors in the reverse significant bit order. I added a 32 bit data 8 bit address control bus that is used to drive the functional units. The epp control unit has been gutted and now only drives this control bus, rather than the old design that effectively replicated the registers used in the functional units as inputs. This change saved a bunch of gates. This change also reduces the already very low parallel port command bandwidth, but it leaves the TVC with a pretty clean internal structure that is also not tied to an 8 bit wide command bus. The problems with the texture mapping demonstrated when the textures are reversed are not memory controller related, but rather are due (I think) to a problem in the texture coordinate signed/unsigned fixed point math. I have not looked very deeply into this problem yet. There are oodles of bugs in the memory controller that I still have no intention of fixing until I move to a different memory type. Xilinx's webpack 10.1 sp3 is working great under Slackware 12.2 using Digilent's parallel jtag cable and the libusb-driver. I'm running ISE over a remote X11 connection to my main workstation. It works perfectly (and better than under win2k). To download TVC release #4 see http://www.johnculp.net/tvc.html I've got a couple new videos up showing the somewhat fixed utah teapot demo and the new texture mapping demo. -John From theosib at gmail.com Thu Mar 12 09:36:15 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Thu Mar 12 05:38:34 2009 Subject: [Open-graphics] TVC Release #4 aka "T-Mapper" In-Reply-To: <896594299.2435251236842446882.JavaMail.root@mail5.gatech.edu> References: <896594299.2435251236842446882.JavaMail.root@mail5.gatech.edu> Message-ID: <9871ee5f0903120636u25d605bfj514f88776e487be4@mail.gmail.com> Very nice work on your GPU. Is there anything graphical you can show us? Also, I'm very interested in what you have to do to get Xilinx tools working in Linux. Would you be interested in helping us document this? Thanks! On 3/12/09, Culp, John R wrote: > This release implements hardware texture mapping! Texture mapping is > performed at the scanline level. I use 16 bit fixed point math for > texture coordinates in the fpga. Textures are the same 256x256 size as > demonstrated in Release #3's software demo. > > I fixed the bug that created the incorrect color distribution and > black rectangles in the "Utah Spinner" demo. I had specified the pins > on the fpga output lines for the green and blue colors in the reverse > significant bit order. > > I added a 32 bit data 8 bit address control bus that is used to drive > the functional units. The epp control unit has been gutted and now > only drives this control bus, rather than the old design that > effectively replicated the registers used in the functional units as > inputs. This change saved a bunch of gates. This change also reduces > the already very low parallel port command bandwidth, but it leaves > the TVC with a pretty clean internal structure that is also not tied > to an 8 bit wide command bus. > > The problems with the texture mapping demonstrated when the textures > are reversed are not memory controller related, but rather are due (I > think) to a problem in the texture coordinate signed/unsigned fixed > point math. I have not looked very deeply into this problem yet. > > There are oodles of bugs in the memory controller that I still have no > intention of fixing until I move to a different memory type. > > Xilinx's webpack 10.1 sp3 is working great under Slackware 12.2 using > Digilent's parallel jtag cable and the libusb-driver. I'm running ISE > over a remote X11 connection to my main workstation. It works > perfectly (and better than under win2k). > > To download TVC release #4 see http://www.johnculp.net/tvc.html > > I've got a couple new videos up showing the somewhat fixed utah teapot > demo and the new texture mapping demo. > > -John > > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From john.culp at me.gatech.edu Thu Mar 12 13:08:57 2009 From: john.culp at me.gatech.edu (John Culp) Date: Thu Mar 12 08:39:47 2009 Subject: [Open-graphics] TVC Release #4 aka "T-Mapper" In-Reply-To: <9871ee5f0903120636u25d605bfj514f88776e487be4@mail.gmail.com> References: <896594299.2435251236842446882.JavaMail.root@mail5.gatech.edu> <9871ee5f0903120636u25d605bfj514f88776e487be4@mail.gmail.com> Message-ID: <49B941A9.5040400@me.gatech.edu> Timothy Normand Miller wrote: > Very nice work on your GPU. Is there anything graphical you can show us? Err... >> I've got a couple new videos up showing the somewhat fixed utah >> teapot demo and the new texture mapping demo. > Also, I'm very interested in what you have to do to get Xilinx tools > working in Linux. Would you be interested in helping us document > this? I think the Xilinx document "ISE Design Suite 10.1 Release Notes and Installation Guide" and the readme for libusb-driver (second hit on google for me) have the whole documentation angle covered. -John From theosib at gmail.com Mon Mar 16 16:38:10 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Mon Mar 16 12:40:44 2009 Subject: [Open-graphics] Using HQ in some academic research Message-ID: <9871ee5f0903161338p79229386k3162d0f99fe9410c@mail.gmail.com> I'm working on a double modular redundancy "scheme" for unreliable silicon that's wires up processor pipeline stages in similar spirit to this diagram: www.cse.ohio-state.edu/~millerti/in-order.pdf I think it would be trivial to apply this to our own HQ, and as a result have a legitimate reason to mention the OGP in a conference paper. :) All we need to do is hack the top level of HQ and drop it into some test environment where it ran some code in an infinite loop, and we would have some other block in the stimulus that would inject errors into the pipeline. We could then collect statistics regarding its ability to detect particle strike ("soft") errors. Then doing a gate-level simulation, we could also simulate the occurrence of timing errors. Anyone interested in working on this with me? -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From theosib at gmail.com Mon Mar 16 16:45:52 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Mon Mar 16 12:48:26 2009 Subject: [Open-graphics] Instrumenting Icarus Verilog to estimate energy consumption? Message-ID: <9871ee5f0903161345j20a90beew56d2f6e6d306bfc3@mail.gmail.com> How hard would it be to modify Icarus so that it could be given an energy model and generate power consumption estimates? Presumably, this would apply mostly to gate-level simulations where low-level gates and other resources are given switching current models. What would be really cool would be to estimate temperature from that and use that to compute leakage current dynamically. For that, we would need to be able to give it a floor plan. And it would be even cooler still if we could provide a variation model so that it could take into account the differences in switching characteristics between different transistors in the same die. How hard would this be? People doing architecture have lots of existing tools for estimating this kind of stuff, but using something like Icarus, we could be just that much more realistic. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From vogel at ct.metrocast.net Wed Mar 18 20:17:03 2009 From: vogel at ct.metrocast.net (Robert Vogel) Date: Wed Mar 18 16:19:58 2009 Subject: [Open-graphics] Toward an Open Desktop ... References: <9871ee5f0903161345j20a90beew56d2f6e6d306bfc3@mail.gmail.com> Message-ID: <7E4E82635BCA499EA4E4A05B22FD6C52@JUNKNAME> This weekend the Free Software Foundation is holding its annual associates meeting in Cambridge, Mass. Since they are mainly interested in software issues, this project might not interest them. http://groups.fsf.org/index.php/Project_Suggestion_for_an_Open_Machine See www.fsf.org for more details about the meeting. Bob From attila at kinali.ch Sun Mar 22 06:06:57 2009 From: attila at kinali.ch (Attila Kinali) Date: Sun Mar 22 02:09:56 2009 Subject: [Open-graphics] LinuxTag 2009 Call for Projects Message-ID: <20090322110657.e09d6d57.attila@kinali.ch> Moin People, It's again time for the LinuxTag preparations. I plan to go there this year too, hopefully with a working OGD1 to show a bit off :-) For the booth we'd need at least two others to help at the booth to have a good presentation. Other than being there during the day and talking with lots of interesting people it'll exploring the dark side of Berlin during the night ;-) So, any volunteers to help me have fun over there? :-) Attila Kinali Begin forwarded message: Date: Tue, 17 Mar 2009 12:39:43 +0100 From: Marko Jung | LinuxTag To: LinuxTag Project Veterans Subject: [LT-Pro-Veterans] Call for Projects 2009 Dear Projects, We would like to inform you about: == Call for Projects == LinuxTag's philosophy is to promote cooperation between companies and free software projects. Income from the participation of profit-oriented companies allows LinuxTag to finance a professional platform where open projects can present the broad diversity of free software to the public. LinuxTag is looking for projects to participate in this year's exhibition. The Call for Projects contains everything that project members need to know about the conditions. To participate, send a substantive description of your project by March 24th, 2009. You should not wait to the end of the deadline, because we will inform projects, that have been exhibiting at last year's LinuxTag, within a few days after their submission whether they may participate or not at this year's show. We improved the whole process, so please take the time to read through the Call for Projects [1] and before you submit an application using the virtual Conference Center (vCC) [2]. [1] http://wiki.linuxtag.org/w/fp:Call_for_Projects [2] https://vcc.linuxtag.org/ Thank you for your support and please stay tuned. Best regards, Marko Jung on behalf of the Project Committee LinuxTag 2009 -- The true CS students do not need to know how to program. They learn how to abstract the process of programming to the point of making programmers obsolete. -- Jabber in #holo From theosib at gmail.com Sun Mar 22 11:11:02 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Sun Mar 22 07:13:56 2009 Subject: [Open-graphics] LinuxTag 2009 Call for Projects In-Reply-To: <20090322110657.e09d6d57.attila@kinali.ch> References: <20090322110657.e09d6d57.attila@kinali.ch> Message-ID: <9871ee5f0903220811v21f1b18ay1df7705d319162df@mail.gmail.com> There's another show coming up soon in California, and there are some people going who want some materials from us. How about we work together on collecting together some older stuff and maybe some new things too. There's a company that can make OGD1 boards more cheaply in smaller quantities who we're in talks with, and they want to show our design at this show. I'll get you more details. On 3/22/09, Attila Kinali wrote: > Moin People, > > It's again time for the LinuxTag preparations. > > I plan to go there this year too, hopefully with > a working OGD1 to show a bit off :-) > > For the booth we'd need at least two others to help > at the booth to have a good presentation. Other than > being there during the day and talking with lots of > interesting people it'll exploring the dark side > of Berlin during the night ;-) > > So, any volunteers to help me have fun over there? :-) > > Attila Kinali > > > Begin forwarded message: > > Date: Tue, 17 Mar 2009 12:39:43 +0100 > From: Marko Jung | LinuxTag > To: LinuxTag Project Veterans > Subject: [LT-Pro-Veterans] Call for Projects 2009 > > > Dear Projects, > > We would like to inform you about: > > == Call for Projects == > > LinuxTag's philosophy is to promote cooperation between companies and > free software projects. Income from the participation of profit-oriented > companies allows LinuxTag to finance a professional platform where open > projects can present the broad diversity of free software to the public. > > LinuxTag is looking for projects to participate in this year's > exhibition. The Call for Projects contains everything that project > members need to know about the conditions. To participate, send a > substantive description of your project by March 24th, 2009. You should > not wait to the end of the deadline, because we will inform projects, > that have been exhibiting at last year's LinuxTag, within a few days > after their submission whether they may participate or not at this > year's show. > > We improved the whole process, so please take the time to read through > the Call for Projects [1] and before you submit an application using the > virtual Conference Center (vCC) [2]. > > [1] http://wiki.linuxtag.org/w/fp:Call_for_Projects > [2] https://vcc.linuxtag.org/ > > Thank you for your support and please stay tuned. > > Best regards, > Marko Jung > on behalf of the Project Committee LinuxTag 2009 > > > > > -- > The true CS students do not need to know how to program. > They learn how to abstract the process of programming to > the point of making programmers obsolete. > -- Jabber in #holo > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From attila at kinali.ch Sun Mar 22 12:50:57 2009 From: attila at kinali.ch (Attila Kinali) Date: Sun Mar 22 08:53:57 2009 Subject: [Open-graphics] LinuxTag 2009 Call for Projects In-Reply-To: <9871ee5f0903220811v21f1b18ay1df7705d319162df@mail.gmail.com> References: <20090322110657.e09d6d57.attila@kinali.ch> <9871ee5f0903220811v21f1b18ay1df7705d319162df@mail.gmail.com> Message-ID: <20090322175057.acadf213.attila@kinali.ch> On Sun, 22 Mar 2009 11:11:02 -0400 Timothy Normand Miller wrote: > There's another show coming up soon in California, and there are some > people going who want some materials from us. How about we work > together on collecting together some older stuff and maybe some new > things too. I'm currently thinking about buying a acrylic PC case like [1], a micro ATX board, a small disk and a PSU. Put OGD1 into it and get it ready for LT. Excluding the OGD1 that shouldn't cost more than 500-600USD. We could buy a few stuff together yes, but IMHO it doesn't make sense to ship it back and forth europe and america, as the shipping gets soon more expensive than just buying everything twice. What i would like also to have is some roll up banners they usualy have at exhibitions here. It would make a much more proffesional impression than the posters we've now. But therefor we'd need someone to design and have it printed, but i don't have the time for it. > There's a company that can make OGD1 boards more cheaply > in smaller quantities who we're in talks with, and they want to show > our design at this show. I'll get you more details. That sounds promising! BTW: if you want, i could ask a few companies around here who are specialized in prototype production what it would cost to have the PCB produced. But i doubt that we will be much cheaper than in the US. Attila Kinali [1] http://www.clearpc.ca/catalog/product_info.php?products_id=182 -- The true CS students do not need to know how to program. They learn how to abstract the process of programming to the point of making programmers obsolete. -- Jabber in #holo From theosib at gmail.com Wed Mar 25 15:50:13 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Wed Mar 25 11:53:20 2009 Subject: [Open-graphics] Changes to fake writes Message-ID: <9871ee5f0903251250l14d5f9a9i305e614c421bffbe@mail.gmail.com> [To give context for the mailing list, a 'fake' access is where we allow indirect access to some regular memory or engine space in OGD1, but indirectly through PCI config space. This allows us to do setup before we're able to map BARs or when we can't do it anyway, like when in real mode, in BIOS.] We had too much trouble getting fake writes to hold based on can_write. That is, if something was holding up the chip's ability to handle writes, we wanted fake writes to wait the same as any other kind of write. But that proved too challenging, so we're doing something different. Now, when you make a fake write, you must then poll another cfg register and wait for it to go to zero before you can move on and do anything else (and by anything, I mean ANYTHING, reads/writes to any BAR). Here's the relevant part of the memory map now (cfg addresses in decimal): 68 -- fake write address 72 -- fake write target 76 -- fake write data, with auto-increment on the address 80 -- fake write data, with NO auto-increment (like for loading HQ) 84 -- fake write pending status (read) 88 -- fake read address 92 -- fake read data Note that a write to 88 is the _trigger_ to cause a read of a local XP10 lower1k engine space register. You must write that every time you want to read. This causes the read to happen on the following clock cycle, loading the data into a holding register, and that register is only loaded as a result of the write to 88. There's some pipelining on this, but I think there's enough time during the address decode phase of the read transaction for this to compete. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From sxpert at sxpert.org Thu Mar 26 10:31:13 2009 From: sxpert at sxpert.org (=?iso-8859-1?Q?Rapha=EBl?= Jacquot) Date: Thu Mar 26 06:34:23 2009 Subject: [Open-graphics] any news ? Message-ID: <20090326143113.GA10348@sxpert.org> Any news since january 2009 ? Sincerely Rapha?l (which is attempting to slowly save money to buy an OGD some day ;) From theosib at gmail.com Thu Mar 26 10:59:53 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Thu Mar 26 07:03:02 2009 Subject: [Open-graphics] any news ? In-Reply-To: <20090326143113.GA10348@sxpert.org> References: <20090326143113.GA10348@sxpert.org> Message-ID: <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> We have an OGD1 board with VGA and BIOS, and it boots in a PC. We don't have a picture yet, but it doesn't lock up or anything. We can tell that it boots into the OS and everything. We just have some debugging to do in the initialization. On 3/26/09, Rapha?l Jacquot wrote: > Any news since january 2009 ? > > Sincerely > > Rapha?l (which is attempting to slowly save money to buy an OGD some day ;) > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From nicolas.boulay at gmail.com Thu Mar 26 13:15:29 2009 From: nicolas.boulay at gmail.com (Nicolas Boulay) Date: Thu Mar 26 09:18:40 2009 Subject: [Open-graphics] any news ? In-Reply-To: <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> References: <20090326143113.GA10348@sxpert.org> <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> Message-ID: What about the sell of OGD1 ? I'am still surprise by the price. The FPGA cost ~80$. So the BOM must be around 200$. At 300/400$, a market for this kind of video card exist, at least for some hobbyist. 1500$ put it in the professionnal price range, even if it is a low price for them. The card have been annonced in pre-sell in may 2008, almost a year ago. The project looks dead for people outside of this list. Is there a delivery target ? Regards, Nicolas Le 26 mars 2009 15:59, Timothy Normand Miller a ?crit : > We have an OGD1 board with VGA and BIOS, and it boots in a PC. We > don't have a picture yet, but it doesn't lock up or anything. We can > tell that it boots into the OS and everything. We just have some > debugging to do in the initialization. > > On 3/26/09, Rapha?l Jacquot wrote: > > Any news since january 2009 ? > > > > Sincerely > > > > Rapha?l (which is attempting to slowly save money to buy an OGD some day > ;) > > _______________________________________________ > > Open-graphics mailing list > > Open-graphics@duskglow.com > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > > -- > Timothy Normand Miller > http://www.cse.ohio-state.edu/~millerti > Open Graphics Project > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.duskglow.com/open-graphics/attachments/20090326/d2c8a5b1/attachment.html From theosib at gmail.com Thu Mar 26 13:19:11 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Thu Mar 26 09:22:21 2009 Subject: [Open-graphics] any news ? In-Reply-To: References: <20090326143113.GA10348@sxpert.org> <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> Message-ID: <9871ee5f0903261019s6dda6807kac9c560c878c7d4a@mail.gmail.com> The web site isn't updated. Andy often travels out of the country. The retail price of OGD1 is going to be $750. In fact, that's going to be the ONLY price. On 3/26/09, Nicolas Boulay wrote: > What about the sell of OGD1 ? > > I'am still surprise by the price. The FPGA cost ~80$. So the BOM must be > around 200$. > > At 300/400$, a market for this kind of video card exist, at least for some > hobbyist. 1500$ put it in the professionnal price range, even if it is a low > price for them. > > The card have been annonced in pre-sell in may 2008, almost a year ago. The > project looks dead for people outside of this list. Is there a delivery > target ? > > Regards, > Nicolas > > Le 26 mars 2009 15:59, Timothy Normand Miller a ?crit : > > > We have an OGD1 board with VGA and BIOS, and it boots in a PC. We > > don't have a picture yet, but it doesn't lock up or anything. We can > > tell that it boots into the OS and everything. We just have some > > debugging to do in the initialization. > > > > > > > > > > On 3/26/09, Rapha?l Jacquot wrote: > > > Any news since january 2009 ? > > > > > > Sincerely > > > > > > Rapha?l (which is attempting to slowly save money to buy an OGD some > day ;) > > > _______________________________________________ > > > Open-graphics mailing list > > > Open-graphics@duskglow.com > > > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > > > > > > -- > > Timothy Normand Miller > > http://www.cse.ohio-state.edu/~millerti > > Open Graphics Project > > > > > > > > _______________________________________________ > > Open-graphics mailing list > > Open-graphics@duskglow.com > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From nicolas.boulay at gmail.com Thu Mar 26 13:25:05 2009 From: nicolas.boulay at gmail.com (Nicolas Boulay) Date: Thu Mar 26 09:28:15 2009 Subject: [Open-graphics] any news ? In-Reply-To: <9871ee5f0903261019s6dda6807kac9c560c878c7d4a@mail.gmail.com> References: <20090326143113.GA10348@sxpert.org> <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> <9871ee5f0903261019s6dda6807kac9c560c878c7d4a@mail.gmail.com> Message-ID: And what about real avalaibility ? PowerVR begin to be everywhere in embbeded market but is fully closed and stuck by NDA. There is a market even for a small 3D chip with it's own external DRAM interface + a bus interface. Currently, ARM SoC using 3D core engine are completly memory bound. Using the arm or the HW did not change the performance. 2009/3/26 Timothy Normand Miller > The web site isn't updated. Andy often travels out of the country. > The retail price of OGD1 is going to be $750. In fact, that's going > to be the ONLY price. > > > On 3/26/09, Nicolas Boulay wrote: > > What about the sell of OGD1 ? > > > > I'am still surprise by the price. The FPGA cost ~80$. So the BOM must be > > around 200$. > > > > At 300/400$, a market for this kind of video card exist, at least for > some > > hobbyist. 1500$ put it in the professionnal price range, even if it is a > low > > price for them. > > > > The card have been annonced in pre-sell in may 2008, almost a year ago. > The > > project looks dead for people outside of this list. Is there a delivery > > target ? > > > > Regards, > > Nicolas > > > > Le 26 mars 2009 15:59, Timothy Normand Miller a > ?crit : > > > > > We have an OGD1 board with VGA and BIOS, and it boots in a PC. We > > > don't have a picture yet, but it doesn't lock up or anything. We can > > > tell that it boots into the OS and everything. We just have some > > > debugging to do in the initialization. > > > > > > > > > > > > > > > On 3/26/09, Rapha?l Jacquot wrote: > > > > Any news since january 2009 ? > > > > > > > > Sincerely > > > > > > > > Rapha?l (which is attempting to slowly save money to buy an OGD some > > day ;) > > > > _______________________________________________ > > > > Open-graphics mailing list > > > > Open-graphics@duskglow.com > > > > > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > > > List service provided by Duskglow Consulting, LLC (www.duskglow.com > ) > > > > > > > > > > > > > -- > > > Timothy Normand Miller > > > http://www.cse.ohio-state.edu/~millerti > > > Open Graphics Project > > > > > > > > > > > > _______________________________________________ > > > Open-graphics mailing list > > > Open-graphics@duskglow.com > > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > > > > > > > -- > Timothy Normand Miller > http://www.cse.ohio-state.edu/~millerti > Open Graphics Project > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.duskglow.com/open-graphics/attachments/20090326/d8920814/attachment.html From theosib at gmail.com Thu Mar 26 13:49:36 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Thu Mar 26 09:52:46 2009 Subject: [Open-graphics] any news ? In-Reply-To: References: <20090326143113.GA10348@sxpert.org> <9871ee5f0903260759n1f1fde1ejd6ac7d0194e7df31@mail.gmail.com> <9871ee5f0903261019s6dda6807kac9c560c878c7d4a@mail.gmail.com> Message-ID: <9871ee5f0903261049v3cdc678ft514941a5d75a5aae@mail.gmail.com> We're working on a board builder that can make them in smaller quantities. If we can make then 20-off, we can start selling them right then and there. On 3/26/09, Nicolas Boulay wrote: > And what about real avalaibility ? > > PowerVR begin to be everywhere in embbeded market but is fully closed and > stuck by NDA. There is a market even for a small 3D chip with it's own > external DRAM interface + a bus interface. Currently, ARM SoC using 3D core > engine are completly memory bound. Using the arm or the HW did not change > the performance. > > 2009/3/26 Timothy Normand Miller > > > The web site isn't updated. Andy often travels out of the country. > > The retail price of OGD1 is going to be $750. In fact, that's going > > to be the ONLY price. > > > > > > > > > > > > On 3/26/09, Nicolas Boulay wrote: > > > What about the sell of OGD1 ? > > > > > > I'am still surprise by the price. The FPGA cost ~80$. So the BOM must be > > > around 200$. > > > > > > At 300/400$, a market for this kind of video card exist, at least for > some > > > hobbyist. 1500$ put it in the professionnal price range, even if it is a > low > > > price for them. > > > > > > The card have been annonced in pre-sell in may 2008, almost a year ago. > The > > > project looks dead for people outside of this list. Is there a delivery > > > target ? > > > > > > Regards, > > > Nicolas > > > > > > Le 26 mars 2009 15:59, Timothy Normand Miller a > ?crit : > > > > > > > We have an OGD1 board with VGA and BIOS, and it boots in a PC. We > > > > don't have a picture yet, but it doesn't lock up or anything. We can > > > > tell that it boots into the OS and everything. We just have some > > > > debugging to do in the initialization. > > > > > > > > > > > > > > > > > > > > On 3/26/09, Rapha?l Jacquot wrote: > > > > > Any news since january 2009 ? > > > > > > > > > > Sincerely > > > > > > > > > > Rapha?l (which is attempting to slowly save money to buy an OGD > some > > > day ;) > > > > > _______________________________________________ > > > > > Open-graphics mailing list > > > > > Open-graphics@duskglow.com > > > > > > > > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > > > > List service provided by Duskglow Consulting, LLC > (www.duskglow.com) > > > > > > > > > > > > > > > > > -- > > > > Timothy Normand Miller > > > > http://www.cse.ohio-state.edu/~millerti > > > > Open Graphics Project > > > > > > > > > > > > > > > > _______________________________________________ > > > > Open-graphics mailing list > > > > Open-graphics@duskglow.com > > > > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > > > > > > > > > > > > > -- > > > > > > > > Timothy Normand Miller > > http://www.cse.ohio-state.edu/~millerti > > Open Graphics Project > > > > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From theosib at gmail.com Thu Mar 26 20:24:51 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Thu Mar 26 16:28:05 2009 Subject: [Open-graphics] Publicity materials on Traversal's site, useful for tradeshows Message-ID: <9871ee5f0903261724m3f90757s187f63bf3d97dd34@mail.gmail.com> Latest schematic: http://www.traversaltech.com/doc/OGD1V2_RevA.pdf An inaccurate block diagram of OGD1: http://www.traversaltech.com/files/OGD1_diagram.pdf A block diagram of the OGA1 GPU: http://www.traversaltech.com/files/block_diagram.gif An out-dated brochure: http://www.traversaltech.com/files/ogd1p_brochure.pdf Some images: http://www.traversaltech.com/images/ogd1_400x245.jpg http://www.traversaltech.com/images/ogd_pcb.png http://www.traversaltech.com/images/preview_ogd1_showcase.jpg http://www.traversaltech.com/images/preview_ogd1_top.jpg http://www.traversaltech.com/images/traversalincoming-2.png http://www.traversaltech.com/images/traversalincoming-7_12.png http://www.traversaltech.com/images/traversalincoming-half.png http://www.traversaltech.com/images/traversalincoming-third.png http://www.traversaltech.com/logos/ogp_logo_1_fullcolour.png All of the files in this directory are worth looking at (not all are just images): http://www.traversaltech.com/ogd1_images/ High-res closeups of OGD1: http://www.traversaltech.com/ogd1_photos/ Some more publicity stuff: http://www.traversaltech.com/ogd1_press/ogd1-graphics.odt http://www.traversaltech.com/ogd1_press/ogd1-publicity.odt More photos: http://www.traversaltech.com/ogd1_press/ogd1_photo.png http://www.traversaltech.com/ogd1_press/press_ogd1_showcase.png http://www.traversaltech.com/ogd1_press/press_ogd1_showcase.tiff http://www.traversaltech.com/ogd1_press/press_ogd1_top.png http://www.traversaltech.com/ogd1_press/press_ogd1_top.tiff http://www.traversaltech.com/ogd1_press/preview_ogd1_showcase.jpg http://www.traversaltech.com/ogd1_press/preview_ogd1_top.jpg -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From mark.marshall60 at ntlworld.com Fri Mar 27 07:51:39 2009 From: mark.marshall60 at ntlworld.com (Mark Marshall) Date: Fri Mar 27 03:55:10 2009 Subject: [Open-graphics] A small patch to use `defines for targets Message-ID: Hi. One of the things that I've not been too keen on in the verilog source is the multiple definitions of the different targets. This is made worse by the fact that the targets are actually different in different places (sometimes config is 0, other times engine registers are zero). Here is a simple patch that hopefully corrects for that. It adds definitions for each bit the the target register to a verilog file in the include directory, and then uses these bits throughout. I've also rearranged the targets so that the four common to everything are in the low bits, therefore there should be no "target renumbering". I've not checked it in because I have no way of testing it. What do you guys think to such a patch? (I've also moved the bridge commands into the include file). MM PS. I've just noticed that there's a change in fifos/async_video_fifo_DxW.v in this patch. I won't check this in, it's just that the old line was crashing iverilog? -------------- next part -------------- Index: include/internal.txt =================================================================== --- include/internal.txt (revision 516) +++ include/internal.txt (working copy) @@ -83,13 +83,13 @@ # # These are used in the XP10 and in the communication between the XP10 # and the host. -REG_TYPE PCI_TARGET -REG_BIT 0 RW CFG -REG_BIT 1 RW ENG -REG_BIT 2 RW MEM -REG_BIT 3 RW VMEM -REG_BIT 4 RW IO -REG_BIT 5 RW PROM +REG_TYPE TARGET +REG_BIT 0 RW ENG +REG_BIT 1 RW MEM +REG_BIT 2 RW VMEM +REG_BIT 3 RW IO +REG_BIT 4 RW PROM +REG_BIT 5 RW CFG REG_TYPE_ENDS # Bridge Targets Index: include/oga1_defs.v =================================================================== --- include/oga1_defs.v (revision 516) +++ include/oga1_defs.v (working copy) @@ -73,5 +73,26 @@ // Mark Marshall // These should come from the SIG -parameter PCI_VENDOR_ID_OGP = 16'h1227; +parameter PCI_VENDOR_ID_OGP = 16'h1227; parameter PCI_DEVICE_ID_OGD1 = 16'h0000; + +// These are the targets. The same order is now used on both sides of +// the bridge. +parameter TARGET_ENG_MASK = 6'h01; +parameter TARGET_ENG_POSN = 3'd0; +parameter TARGET_MEM_MASK = 6'h02; +parameter TARGET_MEM_POSN = 3'd1; +parameter TARGET_VMEM_MASK = 6'h03; +parameter TARGET_VMEM_POSN = 3'd2; +parameter TARGET_IO_MASK = 6'h08; +parameter TARGET_IO_POSN = 3'd3; +parameter TARGET_PROM_MASK = 6'h10; +parameter TARGET_PROM_POSN = 3'd4; +parameter TARGET_CFG_MASK = 6'h20; +parameter TARGET_CFG_POSN = 3'd5; + +// These are the commands sent over the bridge +parameter BRIDGE_COMMAND_IDLE = 2'h0; +parameter BRIDGE_COMMAND_ADDR = 2'h1; +parameter BRIDGE_COMMAND_RCOUNT = 2'h2; +parameter BRIDGE_COMMAND_WRITE = 2'h3; Index: fifos/async_video_fifo_DxW.v =================================================================== --- fifos/async_video_fifo_DxW.v (revision 516) +++ fifos/async_video_fifo_DxW.v (working copy) @@ -93,7 +93,11 @@ // Grab output data into register // XST will infer sync read from this always @(posedge oCLOCK) begin - oDOUT <= fifo_data[oDEQ ? oheadp1 : ohead]; + //oDOUT <= fifo_data[oDEQ ? oheadp1 : ohead]; + if (oDEQ) + oDOUT <= fifo_data[oheadp1]; + else + oDOUT <= fifo_data[ohead]; end Index: oga1/s3/s3_bridge.v =================================================================== --- oga1/s3/s3_bridge.v (revision 516) +++ oga1/s3/s3_bridge.v (working copy) @@ -109,20 +109,9 @@ output reg test ); +`include "oga1_defs.v" -// Commands -- move to header file! -parameter b_idle = 0; -parameter b_addr = 1; -parameter b_rcount = 2; -parameter b_write = 3; - -// These target numbers are different from in the XP10 -parameter TARGET_ENG=0; -parameter TARGET_MEM=1; - - - // Busy always @(posedge clock) begin bridge_busy <= mem_nearly_full; @@ -150,12 +139,12 @@ //eng_do_write <= 0; case (bridge_cmd_d) - b_addr: begin + BRIDGE_COMMAND_ADDR: begin address <= bridge_ad_in_d[29:2]; // Discard byte offset target <= bridge_flags_d; end - b_rcount: rcount <= bridge_ad_in_d; - b_write: begin + BRIDGE_COMMAND_RCOUNT: rcount <= bridge_ad_in_d; + BRIDGE_COMMAND_WRITE: begin mem_addr <= address[27:1]; // Discard dword offset // Cheat by not combining adjacent writes // This should be easy to optimize later @@ -167,7 +156,7 @@ mem_bytes[7:4] <= {4{address[0]}} & bridge_flags_d; mem_do_write <= 1; mem_do_read <= 0; - mem_enq <= target[TARGET_MEM]; + mem_enq <= target[TARGET_MEM_POSN]; end endcase @@ -175,7 +164,7 @@ mem_addr <= address[27:1]; // Discard dword offset mem_do_write <= 0; mem_do_read <= 1; - mem_enq <= target[TARGET_MEM]; + mem_enq <= target[TARGET_MEM_POSN]; address[6:1] <= address[6:1] + 1; rcount[6:1] <= rcount[6:1] - 1; @@ -198,7 +187,7 @@ mem_rdata_validD, mem_rdata_validD}; always @(posedge clock) begin - if (target[TARGET_MEM]) begin + if (target[TARGET_MEM_POSN]) begin case (return_slice) 0: bridge_ad_out <= mem_rdataA[31:0]; 1: bridge_ad_out <= mem_rdataA[63:32]; @@ -218,7 +207,7 @@ reg [7:0] tdo; always @(posedge clock) begin - if (target[TARGET_MEM]) begin + if (target[TARGET_MEM_POSN]) begin case (return_slice) 0: tdo <= mem_rdataA[31:0]; 1: tdo <= mem_rdataA[63:32]; @@ -248,7 +237,7 @@ bridge_rdata_valid <= 0; tdv <= 0; end else begin - if (bridge_cmd_d == b_rcount) begin + if (bridge_cmd_d == BRIDGE_COMMAND_RCOUNT) begin return_slice <= 0; end @@ -259,7 +248,7 @@ // BIG BIG, MASSIVE NOTE: Need to make sure this // matches up with both PCI writes and how other components // (engine, video) want memory to be organized! - if (target[TARGET_MEM] && rdata_valid[return_slice]) begin + if (target[TARGET_MEM_POSN] && rdata_valid[return_slice]) begin bridge_oe <= 1; /*case (return_slice) 0: bridge_ad_out <= mem_rdataA[31:0]; @@ -313,7 +302,7 @@ always @(posedge clock) begin if (eng_do_write) $display("S3 Writing 0x%x to 0x%x", eng_wdata, eng_addr); if (eng_read_count == 1) $display("S3 Got read data 0x%x", eng_rdata); - if (bridge_cmd_d == b_rcount) $display("S3 Requesting engine read at 0x%x", address); + if (bridge_cmd_d == BRIDGE_COMMAND_RCOUNT) $display("S3 Requesting engine read at 0x%x", address); end // synopsys translate_on @@ -341,18 +330,18 @@ eng_do_read <= 0; case (bridge_cmd_d) - b_rcount: begin + BRIDGE_COMMAND_RCOUNT: begin // We ignore the actual read count, because // it always has to be 1. eng_addr <= address; // Start delay counter at 3 - eng_read_count <= {2{target[TARGET_ENG]}}; - eng_do_read <= target[TARGET_ENG]; + eng_read_count <= {2{target[TARGET_ENG_POSN]}}; + eng_do_read <= target[TARGET_ENG_POSN]; end - b_write: begin + BRIDGE_COMMAND_WRITE: begin eng_addr <= address; eng_wdata <= bridge_ad_in_d; - eng_do_write <= target[TARGET_ENG]; + eng_do_write <= target[TARGET_ENG_POSN]; end default: begin eng_read_count <= 0; Index: oga1/xp10/pci_address_decode.v =================================================================== --- oga1/xp10/pci_address_decode.v (revision 516) +++ oga1/xp10/pci_address_decode.v (working copy) @@ -188,6 +188,7 @@ output reg [2:0] interrupt_enable ); +`include "oga1_defs.v" // DDC section. Move to submodule? reg top_ddc_clk_o, top_ddc_data_o; @@ -224,26 +225,10 @@ wire do_write = do_write_i || do_fake_write; -// Access targets. Move into header! -parameter TARGET_CFG=0; -parameter TARGET_ENG=1; -parameter TARGET_MEM=2; -parameter TARGET_VMEM=3; -parameter TARGET_IO=4; -parameter TARGET_PROM=5; - - reg cache_enabled; -// Commands -- move to header file! -parameter b_idle = 0; -parameter b_addr = 1; -parameter b_rcount = 2; -parameter b_write = 3; - - wire [31:0] cfg_read_data; wire cfg_read_valid; @@ -284,7 +269,7 @@ end else begin bprom_do_read <= 0; // Make sure PROM accesses are always one-shot! - if (start_read && access_target[TARGET_PROM] && !bprom_busy) begin + if (start_read && access_target[TARGET_PROM_POSN] && !bprom_busy) begin bprom_read_addr <= read_address[23:2]; bprom_do_read <= 1; end @@ -295,13 +280,13 @@ // Divide the address space for reg reads between XP10 and S3 wire lower_1k = read_address[17:12] == 0; -wire eng_xp10 = access_target[TARGET_ENG] && lower_1k; -wire eng_s3 = access_target[TARGET_ENG] && !lower_1k; +wire eng_xp10 = access_target[TARGET_ENG_POSN] && lower_1k; +wire eng_s3 = access_target[TARGET_ENG_POSN] && !lower_1k; wire read_cache = cache_enabled && - (access_target[TARGET_MEM] || access_target[TARGET_VMEM]); + (access_target[TARGET_MEM_POSN] || access_target[TARGET_VMEM_POSN]); wire read_direct = eng_s3 || - (!cache_enabled && (access_target[TARGET_MEM] || access_target[TARGET_VMEM])); + (!cache_enabled && (access_target[TARGET_MEM_POSN] || access_target[TARGET_VMEM_POSN])); wire read_local = eng_xp10; @@ -426,19 +411,19 @@ ({32{read_cache}} & cache_data) | ({32{read_direct}} & cache_eng_data) | ({32{read_local}} & local_reg_data) | - ({32{access_target[TARGET_PROM]}} & bprom_read_data) | - ({32{access_target[TARGET_CFG]}} & cfg_read_data); + ({32{access_target[TARGET_PROM_POSN]}} & bprom_read_data) | + ({32{access_target[TARGET_CFG_POSN]}} & cfg_read_data); assign read_valid = (read_cache && cache_hit && doing_read) || (read_direct && cache_eng_valid) || (read_local) || - (access_target[TARGET_PROM] && bprom_read_valid) || - (access_target[TARGET_CFG] && cfg_read_valid); + (access_target[TARGET_PROM_POSN] && bprom_read_valid) || + (access_target[TARGET_CFG_POSN] && cfg_read_valid); -wire bridge_access = (access_target[TARGET_MEM] || access_target[TARGET_VMEM] || eng_s3); +wire bridge_access = (access_target[TARGET_MEM_POSN] || access_target[TARGET_VMEM_POSN] || eng_s3); wire mem_read = read_cache && !cache_hit; @@ -452,7 +437,7 @@ // When to dequeue read return data assign br_deq_read = doing_eng_read_s3 || doing_cache_load; -assign bprom_read_deq = access_target[TARGET_PROM] && deq_read; +assign bprom_read_deq = access_target[TARGET_PROM_POSN] && deq_read; @@ -467,9 +452,9 @@ // Can write freely to CFG // MEM and ENG require that the bridge command fifo have a free entry -assign can_write = access_target[TARGET_CFG] || +assign can_write = access_target[TARGET_CFG_POSN] || eng_xp10 || - access_target[TARGET_PROM] || // need to discard PROM writes + access_target[TARGET_PROM_POSN] || // need to discard PROM writes (bridge_access && (!br_full || !br_enq) && state==s_write); @@ -482,7 +467,7 @@ cache_valid <= 0; br_enq <= 0; br_flags <= 0; - br_command <= 0; + br_command <= BRIDGE_COMMAND_IDLE; load_counter <= 0; cache_replace <= 0; cache_load_addr <= 0; @@ -493,7 +478,7 @@ end else begin // Wipe the cache on any memory write. We could do // write-through later. - if (doing_write && (access_target[TARGET_MEM] || access_target[TARGET_VMEM])) begin + if (doing_write && (access_target[TARGET_MEM_POSN] || access_target[TARGET_VMEM_POSN])) begin cache_valid <= 0; end @@ -509,8 +494,8 @@ doing_cache_load <= 0; doing_eng_read_s3 <= 0; - br_command <= b_addr; - br_flags <= access_target[4:1]; + br_command <= BRIDGE_COMMAND_ADDR; + br_flags <= access_target[3:0]; if (start_write) begin // We catch address early @@ -547,7 +532,7 @@ s_read_count: begin // Sent read address, now need to send read count - br_command <= b_rcount; + br_command <= BRIDGE_COMMAND_RCOUNT; br_data <= load_counter; br_enq <= 1; @@ -574,7 +559,7 @@ br_data <= write_data; br_flags <= write_bytes; br_enq <= do_write; - br_command <= b_write; + br_command <= BRIDGE_COMMAND_WRITE; if (end_write) state <= s_idle; end @@ -655,7 +640,7 @@ .write_address (write_address_i[7:0]), .write_bytes (write_bytes_i), .write_data (write_data_i), - .do_write (do_write_i && access_target_i[0]), + .do_write (do_write_i && access_target_i[TARGET_CFG_POSN]), .can_write (can_write), .decode_address (decode_address), Index: oga1/xp10/xp10_top_level.v =================================================================== --- oga1/xp10/xp10_top_level.v (revision 516) +++ oga1/xp10/xp10_top_level.v (working copy) @@ -468,8 +468,8 @@ .bridge_rdata_valid (bridge_rdata_valid), .bridge_busy (bridge_busy), - .bridge_clock_2x (bridge_clock_2x), - .test (test[0]) + .bridge_clock_2x (bridge_clock_2x)//, + //.test (test[0]) ); Index: oga1/xp10/xp10_bridge.v =================================================================== --- oga1/xp10/xp10_bridge.v (revision 516) +++ oga1/xp10/xp10_bridge.v (working copy) @@ -135,15 +135,9 @@ ); +`include "oga1_defs.v" -// Commands -- move to header file! -parameter b_idle = 0; -parameter b_addr = 1; -parameter b_rcount = 2; -parameter b_write = 3; - - // Busy signals reg s3busy; always @(posedge bridge_clock_tx) s3busy <= bridge_busy; @@ -179,15 +173,7 @@ end end - - - - - - - - always @(posedge bridge_clock_tx or negedge reset_) begin if (!reset_) begin busy_reading <= 0; @@ -199,12 +185,12 @@ bridge_oe <= !busy_reading; // first cycle after rcount // Address, read count, or write data bridge_ad_out <= data_in; - bridge_cmd <= command_in & {2{deq_in && valid_in}}; + bridge_cmd <= (deq_in && valid_in) ? command_in : BRIDGE_COMMAND_IDLE; // Write bytes or access target bridge_flags <= flags_in; if (read_count == 0) busy_reading <= 0; - if (deq_in && valid_in && command_in == b_rcount) begin + if (deq_in && valid_in && command_in == BRIDGE_COMMAND_RCOUNT) begin read_count <= data_in; busy_reading <= 1; Index: oga1/xp10/xp10_bridge_wrapper.v =================================================================== --- oga1/xp10/xp10_bridge_wrapper.v (revision 516) +++ oga1/xp10/xp10_bridge_wrapper.v (working copy) @@ -99,6 +99,8 @@ wire [1:0] command_out; wire [31:0] data_out; wire [3:0] flags_out; + +`include "oga1_defs.v" // Command fifo from PCI to HQ @@ -376,11 +378,7 @@ parameter MEM_READQ_AVAIL = MEM_BASE + 9'h02; parameter MEM_READQ_DATA = MEM_BASE + 9'h03; -// Bridge Commands -parameter BR_CMD_IDLE = 0; -parameter BR_CMD_ADDR = 1; -parameter BR_CMD_RCOUNT = 2; -parameter BR_CMD_WRITE = 3; +`include "oga1_defs.v" /* NOTES The way async_fifo_16_count is designed, the count is often an underestimate. @@ -473,7 +471,7 @@ always @(posedge clock) begin hq2br_cmd_data <= hqio_outport; - hq2br_cmd_type <= BR_CMD_IDLE; + hq2br_cmd_type <= BRIDGE_COMMAND_IDLE; hq2br_cmd_flags <= hqio_addr[3:0]; hq2pci_read_enq <= 0; hq2pci_read_data <= hqio_outport; @@ -481,20 +479,20 @@ // Assign enqueue and command type if port write. if (hqio_enable_out) begin if (hqio_addr[8:4] == (MEM_SEND_DATA_0000 >> 4)) - hq2br_cmd_type <= BR_CMD_WRITE; + hq2br_cmd_type <= BRIDGE_COMMAND_WRITE; case (hqio_addr) PCI_TR_DATA: hq2pci_read_enq <= 1; MEM_SEND_ADDR_MEM: begin - hq2br_cmd_type <= BR_CMD_ADDR; - hq2br_cmd_flags <= 4'b0010; + hq2br_cmd_type <= BRIDGE_COMMAND_ADDR; + hq2br_cmd_flags <= TARGET_MEM_MASK; end MEM_SEND_ADDR_ENG: begin - hq2br_cmd_type <= BR_CMD_ADDR; - hq2br_cmd_flags <= 4'b0001; + hq2br_cmd_type <= BRIDGE_COMMAND_ADDR; + hq2br_cmd_flags <= TARGET_ENG_MASK; end MEM_SEND_READ_COUNT: - hq2br_cmd_type <= BR_CMD_RCOUNT; + hq2br_cmd_type <= BRIDGE_COMMAND_RCOUNT; endcase end Index: pci/target_fsm.v =================================================================== --- pci/target_fsm.v (revision 516) +++ pci/target_fsm.v (working copy) @@ -135,14 +135,8 @@ -// Access target bits -parameter TARGET_CFG=0; -parameter TARGET_ENG=1; -parameter TARGET_MEM=2; -parameter TARGET_PROM=3; -parameter TARGET_IO=4; +`include "oga1_defs.v" - input clock, _reset; input [31:0] ad_i; @@ -162,14 +156,14 @@ input [31:0] read_data; output [31:0] write_data; output [3:0] write_bytes; -output [4:0] access_target; +output [5:0] access_target; output deq_read, start_read, end_read; output do_write; input read_valid; input can_write; reg [31:0] write_data; reg [3:0] write_bytes; -reg [4:0] access_target; +reg [5:0] access_target; reg deq_read, start_read, end_read; reg do_write; @@ -289,9 +283,12 @@ if (config_space) begin address_valid = address[1:0]==0; end else if (io_space) begin - address_valid = decode_target[TARGET_IO]; + address_valid = decode_target[TARGET_IO_POSN]; end else if (mem_space) begin - address_valid = |decode_target[3:1]; + address_valid = decode_target[TARGET_ENG_POSN] | + decode_target[TARGET_MEM_POSN] | + decode_target[TARGET_VMEM_POSN] | + decode_target[TARGET_PROM_POSN]; end end @@ -392,9 +389,12 @@ read_hold <= 0; ad_o <= read_data; - access_target[3:1] <= decode_target[3:1]; - access_target[4] <= decode_target[4] && io_space; - access_target[0] <= config_space; + access_target[TARGET_ENG_POSN] <= decode_target[TARGET_ENG_POSN]; + access_target[TARGET_MEM_POSN] <= decode_target[TARGET_MEM_POSN]; + access_target[TARGET_VMEM_POSN] <= decode_target[TARGET_VMEM_POSN]; + access_target[TARGET_IO_POSN] <= decode_target[TARGET_IO_POSN] && io_space; + access_target[TARGET_PROM_POSN] <= decode_target[TARGET_PROM_POSN]; + access_target[TARGET_CFG_POSN] <= config_space; end s_decode1w: begin @@ -415,9 +415,12 @@ stop_o <= !((can_write || !do_write) && last_phase); devsel_o <= !address_valid; - access_target[3:1] <= decode_target[3:1]; - access_target[4] <= decode_target[4] && io_space; - access_target[0] <= config_space; + access_target[TARGET_ENG_POSN] <= decode_target[TARGET_ENG_POSN]; + access_target[TARGET_MEM_POSN] <= decode_target[TARGET_MEM_POSN]; + access_target[TARGET_VMEM_POSN] <= decode_target[TARGET_VMEM_POSN]; + access_target[TARGET_IO_POSN] <= decode_target[TARGET_IO_POSN] && io_space; + access_target[TARGET_PROM_POSN] <= decode_target[TARGET_PROM_POSN]; + access_target[TARGET_CFG_POSN] <= config_space; end s_read: begin Index: pci/pci_top.v =================================================================== --- pci/pci_top.v (revision 516) +++ pci/pci_top.v (working copy) @@ -151,16 +151,17 @@ assign cbe_oe = 0; assign frame_oe = 0; +`include "oga1_defs.v" wire [31:0] read_address, read_data, write_address, write_data; wire do_write; wire can_write; wire [3:0] write_bytes; -wire [4:0] access_target; +wire [5:0] access_target; wire start_read, end_read, read_valid, deq_read; wire [31:0] decode_address; -wire [4:0] decode_target; +wire [5:0] decode_target; wire set_parity_error, parity_error_enable; @@ -233,7 +234,7 @@ .write_address (write_address[7:0]), .write_bytes (write_bytes), .write_data (write_data), - .do_write (do_write && access_target[0]), + .do_write (do_write && access_target[TARGET_CFG_POSN]), .decode_address (decode_address), .decode_target (decode_target), @@ -313,7 +314,10 @@ always @(posedge clock) begin - if (do_write && access_target[4:1] && can_write) begin + if (do_write && (access_target[TARGET_ENG_POSN] || + access_target[TARGET_MEM_POSN] || + access_target[TARGET_VMEM_POSN] || + access_target[TARGET_IO_POSN]) && can_write) begin if (write_bytes[0]) memory0[write_address[7:2]] <= write_data[7:0]; if (write_bytes[1]) memory1[write_address[7:2]] <= write_data[15:8]; if (write_bytes[2]) memory2[write_address[7:2]] <= write_data[23:16]; @@ -322,8 +326,8 @@ end -assign read_data = access_target[0] ? cfg_read_data : mem_read_data; -assign read_valid = access_target[0] ? cfg_read_valid : mem_read_valid; +assign read_data = access_target[TARGET_CFG_POSN] ? cfg_read_data : mem_read_data; +assign read_valid = access_target[TARGET_CFG_POSN] ? cfg_read_valid : mem_read_valid; reg [1:0] can_write_r; @@ -337,6 +341,6 @@ can_write_r <= 1; end -assign can_write = can_write_r==0 || access_target[0]; +assign can_write = can_write_r==0 || access_target[TARGET_CFG_POSN]; endmodule Index: pci/config_space.v =================================================================== --- pci/config_space.v (revision 516) +++ pci/config_space.v (working copy) @@ -132,10 +132,11 @@ reg read_valid; output parity_error_enable; - +`include "oga1_defs.v" + input [31:0] decode_address; output [5:0] decode_target; -assign decode_target[0] = 0; +assign decode_target[TARGET_CFG_POSN] = 0; input class_other, class_xga, class_3d, allow_66mhz; @@ -161,7 +162,7 @@ reg [29:0] fake_read_addr; output do_fake_read; reg do_fake_read; -input fake_read_data; +input [31:0] fake_read_data; // BAR enables @@ -182,7 +183,7 @@ //wire BAR2_en; reg io_space_enable; -wire BAR0_en, BAR1_en, EROM_en, VGAI_en, MDA_en, CGA_en; +wire BAR0_en, BAR1_en, EROM_en, VGAI_en, MDA_en, CGA_en, VMEM_en; assign BAR0_en = mem_decode_en_b[0]; assign BAR1_en = mem_decode_en_b[1]; //assign BAR2_en = mem_decode_en_b[2]; @@ -240,12 +241,13 @@ VGAI_v = VGAI_v && (address_r[31:7] == 7); end +assign decode_target[TARGET_ENG_POSN] = BAR0_v; +assign decode_target[TARGET_MEM_POSN] = BAR1_v; +assign decode_target[TARGET_VMEM_POSN] = VMEM_v; +assign decode_target[TARGET_IO_POSN] = VGAI_v; +assign decode_target[TARGET_PROM_POSN] = EROM_v; -assign decode_target[5:1] = {EROM_v, VGAI_v, VMEM_v, BAR1_v, BAR0_v}; - - - reg received_master_abort, received_target_abort, signaled_target_abort; reg master_data_parity_error, vga_palette_snoop; reg parity_error_enable, parity_error; Index: pci/target_fsm_syn.v =================================================================== --- pci/target_fsm_syn.v (revision 516) +++ pci/target_fsm_syn.v (working copy) @@ -139,16 +139,9 @@ ); +`include "oga1_defs.v" -// Access target bits -parameter TARGET_CFG=0; -parameter TARGET_ENG=1; -parameter TARGET_MEM=2; -parameter TARGET_VMEM=3; -parameter TARGET_IO=4; -parameter TARGET_PROM=5; - input clock, _reset; input [31:0] ad_i; @@ -391,11 +384,12 @@ if (config_space) begin address_valid = address_r[1:0]==0; end else if (io_space) begin - address_valid = access_target_int[TARGET_IO]; + address_valid = access_target_int[TARGET_IO_POSN]; end else if (mem_space) begin - address_valid = access_target_int[TARGET_ENG] | - access_target_int[TARGET_MEM] | access_target_int[TARGET_VMEM] | - access_target_int[TARGET_PROM]; + address_valid = access_target_int[TARGET_ENG_POSN] | + access_target_int[TARGET_MEM_POSN] | + access_target_int[TARGET_VMEM_POSN] | + access_target_int[TARGET_PROM_POSN]; end end @@ -697,8 +691,8 @@ always @(access_target_int or io_space or config_space) begin access_target_int_pre = access_target_int; - access_target_int_pre[TARGET_IO] = access_target_int[TARGET_IO] && io_space; - access_target_int_pre[TARGET_CFG] = config_space; + access_target_int_pre[TARGET_IO_POSN] = access_target_int[TARGET_IO_POSN] && io_space; + access_target_int_pre[TARGET_CFG_POSN] = config_space; end // Store access target From theosib at gmail.com Fri Mar 27 19:00:01 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Fri Mar 27 15:03:27 2009 Subject: [Open-graphics] open graphics wiki Message-ID: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> Who is in charge of the wiki? I'd like to add someone to the list of people who have write access. Thanks. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From josephhenryblack at gmail.com Sat Mar 28 00:23:50 2009 From: josephhenryblack at gmail.com (Josephblack) Date: Fri Mar 27 20:27:05 2009 Subject: [Open-graphics] open graphics wiki In-Reply-To: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> References: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> Message-ID: On 28/03/2009, Timothy Normand Miller wrote: > Who is in charge of the wiki? I'd like to add someone to the list of > people who have write access. > > Thanks. > -- > Timothy Normand Miller > http://www.cse.ohio-state.edu/~millerti > Open Graphics Project Hmm, I have no access to the settings page. Russell, could you grant me access? Perhaps we should take this off list for the small details.. JHB From rmiller at duskglow.com Sat Mar 28 01:03:45 2009 From: rmiller at duskglow.com (Russell Miller) Date: Fri Mar 27 21:06:02 2009 Subject: [Open-graphics] open graphics wiki In-Reply-To: References: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> Message-ID: <200903272203.46013.rmiller@duskglow.com> On Friday 27 March 2009 21:23:50 Josephblack wrote: > On 28/03/2009, Timothy Normand Miller wrote: > > Who is in charge of the wiki? I'd like to add someone to the list of > > people who have write access. > > > > Thanks. > > > > -- > > Timothy Normand Miller > > http://www.cse.ohio-state.edu/~millerti > > Open Graphics Project > > Hmm, I have no access to the settings page. Russell, could you grant > me access? Perhaps we should take this off list for the small > details.. > Huh, thought you did. I'll take it off list. --Russell From john at foseda.com Sun Mar 29 09:13:29 2009 From: john at foseda.com (John Griessen) Date: Sun Mar 29 05:16:52 2009 Subject: [Open-graphics] A small batch contract manufacturer Message-ID: <49CF73F9.6070801@foseda.com> Have you tried this tiny company for making batches of twenty? I've taled with the owner and they seem for real. You need to do some of the estimating work yourself, and there is a board size restriction of 30 sq. inches until they get a vapor reflow oven. Is OGD1 bigger than 30 in sq? http://www.lil-brother.com/ John Griessen From theosib at gmail.com Sun Mar 29 10:25:12 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Sun Mar 29 06:28:34 2009 Subject: [Open-graphics] A small batch contract manufacturer In-Reply-To: <49CF73F9.6070801@foseda.com> References: <49CF73F9.6070801@foseda.com> Message-ID: <9871ee5f0903290725w315126a9r6b316681c4ec92d8@mail.gmail.com> Thanks! I'll forward this to those who can look into it. On 3/29/09, John Griessen wrote: > Have you tried this tiny company for making batches of twenty? I've taled > with the owner and they seem for real. > > You need to do some of the estimating work yourself, and there is a board > size restriction of 30 sq. inches until they get > a vapor reflow oven. > > Is OGD1 bigger than 30 in sq? > > http://www.lil-brother.com/ > > John Griessen > _______________________________________________ > Open-graphics mailing list > Open-graphics@duskglow.com > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From josephhenryblack at gmail.com Mon Mar 30 05:13:48 2009 From: josephhenryblack at gmail.com (Josephblack) Date: Mon Mar 30 01:17:12 2009 Subject: [Open-graphics] open graphics wiki In-Reply-To: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> References: <9871ee5f0903271600j2281d62dwa1174ebe7d7cbf76@mail.gmail.com> Message-ID: On 28/03/2009, Timothy Normand Miller wrote: > Who is in charge of the wiki?snip Back to the list... we both are admins. JHB ps A big thanks to Russell for promptly helping with any wiki queries. From josephhenryblack at gmail.com Mon Mar 30 05:20:32 2009 From: josephhenryblack at gmail.com (Josephblack) Date: Mon Mar 30 01:23:58 2009 Subject: [Open-graphics] LinuxTag 2009 Call for Projects In-Reply-To: <20090322175057.acadf213.attila@kinali.ch> References: <20090322110657.e09d6d57.attila@kinali.ch> <9871ee5f0903220811v21f1b18ay1df7705d319162df@mail.gmail.com> <20090322175057.acadf213.attila@kinali.ch> Message-ID: Attila wrote: It's again time for the LinuxTag preparations. I plan to go there this year too, hopefully with a working OGD1 to show a bit off :-) Timothy wrote There's another show coming up soon in California, Sounds good. Can you give me dates and times you expect to show - I would want to add a comment on the front of our web page basically saying 'come and meet us'. JHB From theosib at gmail.com Mon Mar 30 19:51:58 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Mon Mar 30 15:55:22 2009 Subject: [Open-graphics] Digg this (Linux Fund raising funds to buy OGD1 boards) Message-ID: <9871ee5f0903301651l38786481iebfe5b631cc687b4@mail.gmail.com> http://digg.com/linux_unix/Fundraising_10_Open_Source_Video_Cards_for_Developers Please digg that. I'm working on a post about this to OSnews. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From theosib at gmail.com Mon Mar 30 21:00:15 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Mon Mar 30 17:03:43 2009 Subject: [Open-graphics] Draft of post to OSnews Message-ID: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> [Critiques, please?] The Linux Fund has just started a fund-raiser to raise money to buy 10 Open Graphics Development boards to give away to developers. Please check it out and donate at http://linuxfund.org/projects/ogd1/. The Open Graphics Project home page is here. If you want to buy an OGD1 board for yourself, place a pre-order their store. The Open Graphics Project (OGP) is not like other open source projects. Their focus is open source hardware. While it's relatively cheap to write software, compile it with GCC, and run it on a Linux box, hardware is expensive to make. Not surprisingly the OGP has progressed at a much slower rate than most software projects. The OGP started in late 2004. By the middle of 2005, they had a complete spec written for an open source graphics card. By 2007, they had completed the design for OGD1, their open source FPGA-based graphics card development platform. In 2008, they started taking pre-orders. After that, it was a matter of getting enough pre-orders that they could justify going to production. Meanwhile, the OGP has developed a fair amount of IP. FPGA logic blocks available under GPL include controllers for PCI, memory and, video, as well as a MIPS-like microcontroller called HQ. Putting those together, they have a partially working implementation of legacy VGA hardware and BIOS that allow OGD1 to boot in a PC as the console. That and a simple driver would allow you to drive two 2048x1536 digital monitors, albeit without hardware graphics acceleration (yet). The Linux Fund has recently come along to kick-start this to the next level. First, they found a PCB production house that should be able to build OGD1 boards in smaller quantities. Second, they decided to ask for donations in a quantity that, together with existing pre-orders, would bring the quantity up to the minimum number. Third, with the Linux Fund on their side, OGD1 is no longer seen as the only chance for the OGP to fund itself, allowing them to cut the price in half, making it much more competitive and affordable. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From paul at codesourcery.com Mon Mar 30 21:16:34 2009 From: paul at codesourcery.com (Paul Brook) Date: Mon Mar 30 17:20:03 2009 Subject: [Open-graphics] Draft of post to OSnews In-Reply-To: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> References: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> Message-ID: <200903310216.35939.paul@codesourcery.com> On Tuesday 31 March 2009, Timothy Normand Miller wrote: > That and a simple driver would allow you to drive two 2048x1536 > digital monitors I think (hope!) this is the maximum analogue resolution, and the digital outputs should be able to go higher. Standard dual-link DVI is more like 2560x1600. Paul From theosib at gmail.com Mon Mar 30 23:36:01 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Mon Mar 30 19:39:28 2009 Subject: [Open-graphics] Draft of post to OSnews In-Reply-To: <200903310216.35939.paul@codesourcery.com> References: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> <200903310216.35939.paul@codesourcery.com> Message-ID: <9871ee5f0903302036m62c17941i7e687d7113db13fb@mail.gmail.com> On 3/30/09, Paul Brook wrote: > On Tuesday 31 March 2009, Timothy Normand Miller wrote: > > That and a simple driver would allow you to drive two 2048x1536 > > digital monitors > > I think (hope!) this is the maximum analogue resolution, and the digital > outputs should be able to go higher. Standard dual-link DVI is more like > 2560x1600. We're not sure what is the maximum analog resolution. The DACs are rated at 330 million pixels per second. But that doesn't mean they really can do that kind of signal quality. We haven't tested it that high. Anyhow, you're right about that resolution. I'll correct it. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project From josephhenryblack at gmail.com Tue Mar 31 04:12:21 2009 From: josephhenryblack at gmail.com (Josephblack) Date: Tue Mar 31 00:15:48 2009 Subject: [Open-graphics] Draft of post to OSnews In-Reply-To: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> References: <9871ee5f0903301800w6b6411e2i9a3e9787aa4e50f4@mail.gmail.com> Message-ID: On 31/03/2009, Timothy Normand Miller wrote: > [Critiques, please?] looks good. I have a couple o comments but it is fine unchanged. > > The Linux Fund has just started a fund-raiser to raise money to buy 10 > Open Graphics Development boards to give away to developers.snip > Meanwhile, the OGP has developed a fair amount of IP. I wonder if we should use another term for this considering our audience..This board will help Linux, like no other graphics card around and we don't want to unnecessarily provoke a poor reaction by those who fail to read past the first line. If we droped the phrase IP, it still seems to make sense... Meanwhile, the OGP has developed a fair amount of FPGA logic blocks available under GPL including controllers for PCI, memory and, video, as well as a MIPS-like microcontroller called HQ. FPGA logic > blocks available under GPL include controllers for PCI, memory and, > video, as well as a MIPS-like microcontroller called HQ. Putting > those together, they have a partially working implementation of legacy > VGA hardware and BIOS that allow OGD1 to boot in a PC as the console. maybe.. Putting those together, OGD1 can already boot in a PC as the console with a partial implementation of legacy VGA hardware and BIOS. > That and a simple driver would allow you to drive two 2048x1536 > digital monitors, albeit without hardware graphics acceleration (yet). When I read this I wondered how much of this driver is done? also perhaps instead of: albeit without hardware graphics acceleration (yet). 'with hardware graphics acceleration soon to be started upon.' (? or something) > > The Linux Fund has recently come along to kick-start this to the next > level. First, they found a PCB production house that should be able > to build OGD1 boards in smaller quantities. Second, they decided to > ask for donations in a quantity that, together with existing > pre-orders, would bring the quantity up to the minimum number. Third, > with the Linux Fund on their side, OGD1 is no longer seen as the only > chance for the OGP to fund itself, maybe.. OGD1 is no longer seen as the sole source of fund raising for OGP allowing them to further reduce the price, making it much more competitive and affordable. Anyway, looks good JHB From theosib at gmail.com Tue Mar 31 15:37:03 2009 From: theosib at gmail.com (Timothy Normand Miller) Date: Tue Mar 31 11:40:33 2009 Subject: [Open-graphics] OSnews Message-ID: <9871ee5f0903311237h38b8ef60q72f3941d75306be7@mail.gmail.com> Either they're back-logged, or they're rejected my submission. Anyone else want to take a crack at it? -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project