On 11/27/07, Terry Hancock <[EMAIL PROTECTED]> wrote: > Thank you, that's a lot of info. BTW, that's "EDIF" not "EDID", right?
Oops. You're 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?). Well, I've seen EDIF before, but I don't remember it very well. I don't recall if gates and links can be annotated with locations or not. > 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? Yeah, usually, the output of the synthesizer is an EDIF netlist. > Because the special nature of an ASIC is mostly handled at the > "place-and-route" level, isn't it? When we say that the netlist connects "gates," we don't necessarily mean and gates and or gates. Different target devices have different primitives, and the EDIF netlist would target those primitives. For instance, Xilinx FPGAs have these 16-bit LUTs that are used for arbitrary 4-to-1 logic gates, memory cells, etc. In addition, they have large block RAMs, multipliers, and attached to the luts, extra XOR gates, flipflops, multiplexers, etc. Often, ASICs have much simpler cells, and the function of each cell is selected by how the (arbitrary) metal (routing) layers are hooked up. > 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. In large part, what we'll do is wrap differences with common interfaces. For instance, if an ASIC has 8k bit blocks, and we're assuming 16k bit blocks from the FPGA, then we'll write a wrapper module around each device's primitives and instantiate the wrapper where we need RAM blocks. Most random logic is just expressed in Verilog code that the synthesizer will handle properly. Then some special things like clock managers will just have to be specially written for each architecture. > 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) In Verilog, you're modelling (at an abstract level) just wires and gates. Imagine being able to put probes on as many wires as you want and observe them over time. When you run a simulation, that's what comes out of the simulator, and then you use a waveform viewer to look at what happened. For a simulation, we'd wrap or HDL design with a test harness that provides appropriate test stimuli, and we check to make sure that the logic behaves appropriately. What's really nice is that you're not stuck looking at just outputs. If an output is wrong, you can dig into the design and work your way back until you find what went wrong. Fix your bug and resimulate. Another way to look at it is like having a debugger that logs everything your program does, and then in the viewer, you can examine everything that happened over the run of the program. > 3) Verilog model --Icarus--> netlist --Xilinx tools--> FPGA board which > can be tested as a graphics card (will be possible when OGD1 is shipped) Icarus can synthesize to a generic netlist, but we'd use the synthesizer that comes with the Xilinx tools. So just remove Icarus and netlist from that sequence. > 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). Remove Icarus and netlist from that. We'd probably have to buy a license for one of the really expensive tools like Cadence's Build Gates or Synopsys Design Compiler. We would use that and provide the netlist to the fabricator who would be responsible for P&R. > 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). Icarus is what we use for simulation, not synthesis. And when we run into bugs with Icarus, we're forced (*grumble*) to use ModelSim. (We have commercial licenses for this stuff.) -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
