We seem to be converging here, so I'm going to snip less than I
usually would.
On Tue, Sep 06, 2005 at 09:48:17PM -0400, Timothy Miller wrote:
> On 9/6/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
>
> >
> > OVERALL ARCHITECTURE NAME
> > Working from earlier suggestions in this thread, I suggested that
> > OGA be the generic name for the entire graphics architecture being developed
> > for the ASIC and its board products.
(snip)
> > If we're wildly successful, there may be succeeding generations of
> > Open Graphics Architectures, with different register interfaces. They could
> > be distinguished as OGA-1, OGA-2, etc.
>
> Ok, this is good.
>
> >
> > DRIVER NAME
> > Since all OGA (or OGA-1) products should look the same to the
> > driver,
> > the X.org driver could reasonably be named oga.
>
> When we're still working in FPGA form, chip revisions
Chip revisions? Or FPGA bitfile revisions? Load files can be
packaged up with the drivers as snapshot distributions.
> will come out on
> a regular basis. It would be a pain to try to keep every driver
> backward compatible, so we'd probably have a driver release with each
> bitfile revision.
That's common enough in software development. Everybody is used to
software modules with decimal points in their revision numbers, and module
filenames with digits in them.
> > SPECS AND STANDARDS
> > The specs that document the Open Graphics Architectures (OGA-1 and
> > any later-generation successors) could be issued as Open Graphics Project
> > documents. The typical numbering practice in standards organizations is to
> > give each document a unique identifier made up of three fields: the name of
> > the issuing organization, a unique integer, and a revision letter.
> > Following that familiar practice, all published documents that OGP
> > standardizes would form the OGP series.
> > As an example, the IPC standard for printed circuit board acceptance
> > criteria is formally called ANSI/IPC 600 or ANSI/IPC-600. It was initially
> > issued without a revision letter. The next official version was
> > ANSI/IPC-600-A. I think it's up to D or E now.
> > Since we wouldn't seek accreditation from ANSI or ISO as an official
> > standards body, our prefix would be plain OGP. I suggest reserving that
> > letter combination for OGP standardization documents, and not use it in any
> > part numbers or trade names. Thus, OGP documents would be numbered OGP-1,
> > OGP-2, and so on.
>
> Ok. Will we want to keep any correspondence between OGP and OGA
> numbers?
I don't think that's practical, or even desirable. For one thing,
I've suggested that OGA be a trade name. To be useful as a marketing name,
it should be stable over long periods. It would only get a new suffix digit
when the architecture goes through a major generation change. It's not even
essential that OGP recognize the OGA name as such; OGA could be strictly a
Traversal product family trade name if desired.
If the experience of other standards organizations is any guide,
detailed specifications need small updates and clarifications quite
frequently. Also, it's entirely possible that OGP will find it convenient
to divide up the OGA-1 specification into several documents, dealing with
different aspects of the architecture. (Of course, instead of calling these
different documents OGP-2, OGP-3, OGP-4, etc. we could call a related group
OGP-2-1, OGP-2-2, OGP-2-3, etc. Other organizations sometimes do that so
related documents are grouped together.)
> I suppose we'd start out with OGP 1.0 and eventually we'd
> get to OGP 1.12 or something and decide that's got what we want as a
> final design and designate that to correspond to OGA 1.0. Is that
> what you have in mind?
We could, but it's not usual to use decimal points in standards
document numbers. It's more common to use an integer followed by a revision
letter in a released document. If you're thinking about unreleased drafts,
I don't think there's a universal practice, but we could maybe speak of
OGP-1 Draft 3, OGP-1 Draft 4, etc. Decimal points in draft numbers are
probably OK as long as outsiders don't have to deal with them as released
documents. Even SVN-style branch numbering is probably OK, as long as we
keep it internal, and use conventional revision letters for all released
versions.
I suppose we could pre-reserve OGP-1 for either a monolithic
document or the root number for a suite of specifications for the OGA-1
architecture. I suspect other revision-controlled documents will soon
spring up, so the match-up will break up. Although, if we reserve integers
1-9 for major OGA specs, it might last a long time. Somewhere we'll need a
standard for various internal practices, such as how we create and number
documents, what file formats we use internally, a number assignment log,
etc. Perhaps we might begin those at OGP-10.
> > ASIC PART NUMBERS
> >
> > The biggest problem in IC part numbering is to avoid conflict with
> > the hundreds of thousands of existing part numbers. There are
> > well-established IC part number format practices. ICs aren't sold directly
> > to computer users or builders, so they can be numbered according to IC
> > practices.
>
> Yeah, the primary purchasers are ourselves and embedded-systems vendors.
>
> > It's very common to pick a 2 or 3 letter prefix to uniquely
> > identify the manufacturer. This opens up an entire conflict-free universe
> > of company part numbers.
> > Following practices used by National Semiconductor, Analog Devices,
> > and Linear Technology, I proposed TRV as a Traversal prefix, and TRV14 as
> > the basic part number for the first OGA chip design. It would have suffix
> > characters for performance grade, temperature range, and package -- again,
> > in accordance with typical industry practice.
> > I researched TRV as a company prefix and TRV14 as an IC part number,
> > and found them free of conflicts. Actually, TRV10 and up were all free.
>
> What are TRV1 thru TRV9 used for, and is there any reason to be
> concerned about how their owner would feel about us using 10+?
I didn't find any usage of TRV and a single digit. The only reason
I suggested starting with 2 digits is that it fits typical industry
numbering formats for ICs more closely, so recognition of the sub-fields in
the number should be easier.
> > GRAPHICS BOARD PART NUMBERS (NAMES)
> >
> > Your suggestion to use OGC for cards using OGA chips should work
> > well. OGC could be both a generic trade name for a broad family of boards,
> > and the start of the part number structure. Boards are likely to spawn new
> > generations much faster than chips, so it would probably be wise to put a
> > number after the prefix right from the beginning, as you show below. As
> > noted earlier, I'd also include the bus type in the prefix characters before
> > the first dash, because each bus type requires a separate bare board layout,
> > and is thus a distinct product family.
>
> Ok. And would there be any correspondence (roughly) between OGA and
> OGC numbers?
Nope, don't think so. OGA-1 would identify the logical architecture
used in the first ASIC (and in any later ASIC that doesn't radically change
the interface specs). OGA-2 would come out years down the road, when OGP
and Traversal are ready with some radical new architecture and an amazing
new ASIC.
Traversal might create many generations of board-level products
using that first OGA-1 compliant chip. (How many Ethernet board types are
there that use the 8390 chip?)
So, the data sheets for OGC1P, OGC1A, OGC2E, OGC3P, etc. might all
show the TRV14 (TRV10?) chip, cite the well-known OGA-1 register model, and
specify the oga driver.
> > > As for the PCB, one chip will give us many boards.
Right. Discussed above.
> > > We could just give
> > > them OGC names, completely independent of of the ASIC revision. And,
> > > as discussed before, we could name the model where a letter
> > > corresponds to a feature, of course preferring popular letters like
> > > 'X', 'L', 'Z', and 'Q'. :) So, we'd have the basic board being the
> > > "OGC1 X" (because it has TV), and a version that has twice as much
> > > memory is the "OGC1 XL", etc.
> >
> > When you get into specific features, we should be dealing with part
> > numbers, not trade names. It might be helpful to have a few names for broad
> > families of boards, such as "the OGC1 family". The logical association
> > between a few family trade names and a large block of systematically
> > assigned part numbers might also be helpful, but it should be remembered
> > that names and part numbers are different things with different purposes.
> > Part numbers don't contain spaces. Ever. For any kind of product.
> > MRP managers will scream bloody murder if you try it. They don't even like
> > slashes, or other characters that have special meaning in command lines.
> > I've been screamed at for that. The accepted character set for part numbers
> > consists of letters, digits, dashes, and decimal points. Anything else
> > should be considered with great care.
> > So, a legitimate part number for a PCI graphics board belonging to
> > the OGC1 family, with an OGA chip and TV and DVI output options, might be
> > something like:
> >
> > OGC1P-128VD
>
> That works for me.
>
> >
> > The standard options should have fields at fixed locations in the
> > part number, and have mnemonic coding if possible. This marketroid stuff
> > with X and XL having purely arbitrary meanings, if they mean anything at
> > all, is a PITA to someone trying to figure out what to order. Call the
> > video-out option V or TV, or something a customer can remember.
And, fields in the part number that have some quantitative meaning,
such as VRAM size, should be encoded numerically with some obvious relation
to the physical quantity. Such as, 128MB is encoded as 128.
> > DEVELOPMENT BOARD PART NUMBERS (NAMES)
> >
> > > >
> > > > We'd need a different name for the FPGA development board, since
> > > > it's not a fixed implementation of OGA or whatever we finally call it.
> > > > I
> > > > suggested Bridgehead the other day (or Beachhead). Opinions?
> > >
> > > I don't see why we can't continue with the same naming convention. We
> > > could use OG, because it IS associated with the project, or we could
> > > use TT because it's a Traversal product, so it's TTP1 or something
> > > like that. I think OGP for that is nice, but it might cause
> > > confusion, unless the Open Graphics Project is renamed to something
> > > like the Open Graphics Foundation, but that's pointless until there's
> > > a group of contributors large enough to need their own governance.
> >
> > Well, if you buy the idea of reserving OGP for the OGP document
> > series, how about OGD (for development) or OGF (for FPGA)? Not that there's
> > anything wrong with OG, but OGD is perhaps more specific. OGD could be both
> > a family trade name for all the versions of development boards, and the
> > prefix for development board part numbers.
> > I'd still tack on a series number and bus letter, to create a number
> > universe that can encompass later design generations and multiple bus types;
> > thus, the first designs would have part numbers that begin with
>
> I prefer OGD.
>
> >
> > OGD1P
> >
> > How's that sound?
>
> Brilliant! :)
OK, OGD as both a family name and the first 3 characters of each
part number in the development board family.
I think we have convergence here. Let's see if your partners and
the rest of the project members approve. If they do, I could maybe take a
first whack at writing a standard for Traversal product number formats, as a
companion to the document I shipped over a few days ago. BTW, I have a few
thoughts toward cleaning that up a little.
...
We're getting close to actually assigning some numbers to parts and
doucments.
Where are we going to keep the number logs? Conventional
single-site drafting departments almost always keep number logs on paper
with pencils, so that computer accidents (or the obsolescence of entire
generations of computer technology) don't result in irrecoverable chaos.
Does Traversal have an office yet? Or is the team permanently dispersed?
If the latter, maybe the best possibility is to keep the live number logs
on-line as wikis, and establish a procedure to back them up on floppies at
several locations at set times. Good floppies last at least 25 years, and
plain text on IBM-formatted media is not going to go obsolete in the
foreseeable future. Hard copy is more permanent, but floppies can be
uploaded for restoration or hardware replacement.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
