FEEDBACK A forum for readers to speak their mind on issues that are important to the design community

PDEF can handle 2D info

To the Editor:
I enjoyed Mark Vancura's article regarding the need for portable 2D descriptions ["DSM Needs a Rich Infrastructure," January, p. 14].

You may not be aware, but LSI Logic proposed changes for PDEF to do similar things for datapaths, and in the standardization process, the IEEE P&C working group made it general enough to use for chip floorplans too.

Basically what was added was symbolic placement directives for pins and cells. The placer/planner still needs the algorithms that do the packing or stretching, but the file format doesn't have the dimensions hard-coded anymore. It just tells you what is relative to what.

All the information is available at http://vhdl.vhdl.org/vi/dpc/dpc-pandc. This and other changes are being incorporated into PDEF by the IEEE, and the final draft is nearing completion and then for voting on.

For the example, in the article, here's one way, off the top of my head, that you could do packing:

(CLUSTER "top"
	(CONTENT_ORDER vertical)
	(CLUSTER "bottom"
		(CONTENT_ORDER 


					 horizontal)
		(CELL MAC3 )
			(CELL MAC4 )
			(CELL REGION_B )
			(CELL MAC8 )
			(CELL MAC7 )
	)
	(CLUSTER "middle"
		(CONTENT_ORDER 


					 horizontal)
		(CLUSTER "left"
			(CONTENT_ORDER 


					 vertical)
			(CELL MAC2 )
			(CELL MAC1 )
		)
		(CELL REGION_M)
		(CLUSTER "right"
			(CONTENT_ORDER 


					 vertical)
			(CELL MAC6 )
			(CELL MAC5 )
		)
	)
	(CELL REGION_T)
)

Pins for each cluster can also be placed relative to the underlying rows and columns or previous pins on the cluster.

In PDEF a cell can be a logical gate or module, and you can mix cells, clusters, or both together. If you add the GATE_NAME attribute to the cell, you can use it as a hierarchical reference to another design that is also symbolically described in PDEF.

Kevin R. Grotjohn
Design Engineer
Synthesis and Datapath Tools
CAD Architecture Group
LSI Logic Corp.
Milpitas, Calif.

Mark Vancura replies:
I'm glad Kevin Grotjohn enjoyed the article and is working to get similar changes in place. Of course one of the reasons for the article was to get more of us designers asking for the same thing from EDA vendors. Affirming each other's work will also spawn new requests from other users, and eventually the right thing will be done.

I would make one observation about the symbolic or relative placement or orientation features Kevin's suggested for PDEF. It will take a little more than a packing algorithm to deterministically pack a floorplan based on that input. The semantic I see missing is information to specify which blocks to pitch-match and which blocks to expand or contract. In contrast, because graphics windows must expand and contract elegantly, the semantics found in the Tcl/Tk pack commands are very useful and important.

As he notes, pin locations, which are also 2D data requiring a portable specification, can benefit from a similar packing approach. A paper I presented at DesignCon98 offers a bit more insight into the pins aspect.

The hierarchical referencing in PDEF sounds useful to avoid highly repeated or seemingly redundant code for very regularly structured devices, and capturing that kind of structure can only help for future implementations.

More on Unix vs. Windows

To the Editor:
I would like to comment on your Focus Report on Windows EDA tools in the October issue [p. 40]. Yes, you can compare a single tool running on a PC and a workstation, but there's also the issue of user productivity. In an environment in which you write HDL code, run simulations, and synthesize, a major consideration is file manipulation. The Unix commands ( grep , sed , awk , vi , etc.) provide a significant boost to productivity. That's without considering the slow-down caused by the PC's graphical interface.

If you're sitting in front of a PC, how quickly can you print a hard copy of a directory listing? Is it as easy as |s -| >|pr ? Can you generate a list of files that were written by a specific user: |s -| | grep "user_name" ?

Until this capability's available, I'll keep my PC at home so I can play Doom-II.

Dan Pinvidic
Senior Principal Engineer
Qlogic Corp.
Costa Mesa, Calif.

EDA vendors don't meet designers' needs

To the Editor:
Thank you for your three-part series on users' experiences with deep-submicron design ["Readers Speak Out on Deep Submicron," November, p. 16; December, p. 20; January, p. 24]. In my opinion, though, we need to talk more about attitude in the industry and less about specific tools or flows. Big-company people won't tell the whole truth (they can't), and we can end up with "Anonymous" everything.

There are many reasons why some big companies, like Digital, Intel, IBM, and Motorola, invest heavily in internal CAD.

First, vendors generally don't use users' inputs for their product specification. When they do, there's always a delay between the specification and delivery, so by the time a tool comes out one to two years later, the reality is already different from what they had based their planning on. Only in the case of internal CAD development groups is there an ongoing relationship between user and developer so that at the end of the design project the tool will deliver what was expected and be up to date for the next project.

Second, EDA vendors are delivering new tools without spending the time and effort to explain to the user community what the flow is or the philosophy and the strong and weak points of their software. And there are simply too many conflicts of interest between marketing and sales on one side and development on the other to allow that to happen.

Small companies want and have to work with tool vendors to develop new tools because they can't afford to invest in CAD development. Big companies think that they get a better competitive edge by developing new tools, but in the long run this advantage plays against them. Look at the place-and-route market today.

Another big problem is training. Vendors are doing very poorly in training new engineers not only to use the tools but to squeeze the most out of them. There are plenty of training courses for beginners but not enough, and not good enough ones, for advanced users.

Vendors (sales and marketing) also are doing a very poor job in promoting the right tool for the job and explaining the good and the bad in each tool. In many cases, if a new user is looking for answers he or she can get honest ones only from another user who already knows the tool.

Are we ready to do something to solve the gap between hardware design needs and software development tools?

Dan Clein
Manager, IC Layout
Semiconductor Division
MOSaid Technologies, Inc.
Kanata, Ont.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to miker@isdmag.com.

integrated system design  March 1998