Timothy Normand Miller wrote: > Narrowly, OGA is just a drawing engine, for which we have only some > snippets of proofs-of-concept code for litle things like reciprocals, > fp adders, etc. Broadly, OGA includes PCI, video, memory, etc., of > which we have a number of important things completed.
Okay, so there's a "greater" and a "lesser" OGA (Just like a tiny city :-) ). >>The result of synthesis, called a "netlist" is the input for tools used >>to program an FPGA or to design an ASIC. > > There are netlists at different levels of abstraction. There are > technical names that I can't recall, but anyhow... You can have a > logical netlist that is just the Verilog code converted into > appropriate logic blocks for the target technology. Then you can, let > me make up a word, physicalize it via place and route, which assigns > physical locations and interconnects to those logic blocks. I guess > you can call this a physical netlist, and unlikely to be in the same > format as the logical netlist. EDID is used somewhere in there. Then > you can back-annotate the logical netlist with timing information that > you get from P&R. If you simulate the original Verilog code, that's > called an RTL-level simulation. If you simulate the back-annotated > netlist, that's called a gate-level simulation. Thank you, that's a lot of info. BTW, that's "EDIF" not "EDID", right? Is what you're calling a "physical netlist" really a "netlist" anymore? In my experience with PCBs, a "netlist" contains only what's connected to what, not where they are located spatially. (Admittedly, I'm not sure what the result of P&R is called -- for a PCB, *I* refer to a "PCB layout", but I don't know where I picked up the term. Maybe I just made it up?). >>5) The same netlist is also the input for creating an ASIC, but in that >>case, the tools used will be more sophisticated, proprietary, and >>possibly even custom in-house tools used by the ASIC manufacturer. > > No. We would synthesize the original Verilog code to target the ASIC, > which would be quite different from the FPGA, so the mapping to logic > blocks would be different. Okay, right -- you'd redo some design work for an ASIC obviously. But the *format* for the "logical netlist" is the same, right? Even though the design will be modified to take advantage of the greater flexibility of ASIC design? Because the special nature of an ASIC is mostly handled at the "place-and-route" level, isn't it? I'm just trying to get a handle on what the toolchain looks like, and where the tradeoffs happen as you move from a simulated design, to an FPGA, and then to an ASIC. This is important in order to communicate *why* one does it that way. So, far, I have this, w.r.t. OGA development cycles: 0) Concept -- just a verbal description and the block diagram. 1) C++ model --gcc--> OGA simulator (existing) 2) Verilog model --Icarus--> netlist --GTKWave--> simulation testing via waveforms ((?)I don't really get how this is done) (very incomplete) 3) Verilog model --Icarus--> netlist --Xilinx tools--> FPGA board which can be tested as a graphics card (will be possible when OGD1 is shipped) 4) Verilog model --Icarus--> netlist --(OPAQUE contract service)--> ASIC graphics card is directly usable (this isn't really a "development cycle" because it takes months and close to a million dollars each cycle). I'm creating a diagram based on this. It doesn't really matter that "Icarus Verilog" isn't the only synthesizer available, it's more that it's an example, and probably what is being used in OGP (at least, it's mentioned in the wiki, and seems fairly mature). Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
