Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Wednesday, May 21, 2008

New Software Tool Helps with Floorplanning for System on a Chip

Magma takes floorplanning to another level, so to speak

"Floorplanning for SoCs seems to be a subject rife with paradox. On one hand, the exercise of iteratively refining the chip's floorplan seems to be the axel that holds hierarchical design together. On the other hand, improving the floorplan always seems to require one more level of detail than is currently available to the planners. So invariably, the floorplan is based on estimates of the size, shape, and timing of the blocks, and its quality depends heavily on the experience of the senior design staff...

"Next, Hydra can automatically generate primary floorplans, including creation of voltage domains, pin and pad placement, and gradual definition of the inner shapes of the blocks. At this point the tool can work interactively with designers to absorb, for example, information about the shape and location of hard IP blocks. The tool also creates partitions in the logical hierarchy automatically, impacting pin placement and timing as things get laid out.

"The information thus generated is passed as constraints to a shaping engine, which shapes the partitions that have been defined on the logical hierarchy, and also places and legalizes macros with a shape- and congestion-aware auto-placement engine. With this process complete, Hydra can automatically generate power grids and clock tree hierarchy. At this point the tool can generate production-quality top-level clock structures and prototype-quality block-level clock trees, Bali says. Hydra can also work with Magma's package co-design tools on placing bumps, I/O cells, and redistribution layer information along with the emerging floor plan...

"A key part of the process now, according to Bali, is budgeting. The information Hydra has generated in the process of constructing the floorplan gets pushed down to the block level as timing budgets and other constraints for the block implementation tools. As blocks are implemented, Hydra allows abstraction of detailed block designs back into the floorplanning process to refine the emerging picture of the full chip. By maintaining relative floorplanning constraints, the tool can incorporate changes without disrupting the rest of the plan.Thus, Magma claims, the tool provides a single cockpit for managing an hierarchical design from early exploration through implementation and into the final assembly process. Bali says that Hydra is unique in its ability to serve the team from planning through prototyping, and on to the preparation of the production-ready floorplan."

Tuesday, November 20, 2007

Breakthrough Idea: How to Prototype Software

Been thinking about this one for a while, and I got it.

Consider a software group writing a program for in-house use. The biggest problem is communication between the software group and the users. Creation of a dumb prototype is a well-known attempt to solve the problem. However, as I envision the creation of the prototype, I can see many problems potentially developing.

Essentially, time must be invested, people from two different departments must communicate, tensions may arise, and ultimately, the task of prototyping may be abandoned rather too easily at any time. The software group would like to abandon the task because it's not the sort of thing they like to do: they want to get on with writing the program. The users would like to abandon the task because they do not enjoy interacting with the software group.

In addition, the users have been assured by the software group that the writing of this software is really quite a simple and easy task that does not require the burdensome process of writing a prototype---imposed by the rather stupid types in management, at any rate. Naïvely, viewing the whole situation as a "simple, straightforward technical problem", the user group alludes with the software group in prematurely terminating the task of prototype-building, which in any case seems to be inordinately difficult for reasons that no one can quite understand. Happily, once the prototype task is abandoned, the software group can get down to the real business of writing the program and the user group can get down to their real job whatever it happens to be.

Unfortunately, the reason the prototype was difficult to write was because the task of the users that the software is designed to integrate with---a task which seems so simple to the software engineers that only a moron could be doing it for a job---is, in fact, complicated in a variety of subtle ways. Not to worry, all of the subtleties will turn up---later, after the software is written and tremendous work and effort has been put into doing so.

Okay, that's the problem. I know what you are thinking, "What a brilliant formulation of the problem!" However, let me modestly point out that the formulation of the problem is fairly obvious and well known.

Okay, here's the solution: we create super simple, super user-friendly prototype building software designed explicitly for non-programmers (i.e. "users") to use. Included with the product would be a "manual." (see, "Software; Ancient History in your encyclopedia for an explanation of this term.) However, instead of a nice, bound booklet with high-quality color illustrations, this manual would be online, that is to say it would be a living document.

Different versions of the manual would be written for people in different professions, the point of view of the manual being the process of getting some particular task done such as lawyering, being an accountant, or more specifically, deciding who gets to take out a loan to buy a house, helping someone write up a tax return, designing a of building out of steel, designing interior components like door handles for a car, etc.

Instead of a carefully crafted document designed to last for the ages, I envision a series of down- and-dirty versions of the manual. Scratch that, what I mean is there would be a core manual describing operations and then a variety of intros aimed at different professions. The idea being to not only tell people how to use it but to convince them that it's important to use it. There would also be a general intro for everyone, describing the perils of writing software without an effective prototype.

Sunday, August 26, 2007

Participatory Music Site

This idea is pretty far out. Increasingly, people are using the Internet to find rock groups they enjoy listening to. The Internet is then further utilized to allow these musical groups to have tours that garner them just enough money to support themselves on a low level.

In addition, the software for creating music is becoming increasingly sophisticated and powerful in terms of its effects but also increasingly easy to use. What if there was a way for users to not only find music they like on the Internet but add their own input to the music, changing it into something that fit their tastes better?

Once the user had made changes to a particular song, the web site could remember those changes and always apply them to the song when that user played it. Users could listen to each other's versions in a My Space-like community. The types of changes the user made in one song could be automatically applied to another song created by the same musical group, to make it something the user more wanted to listen to.

These types of changes could certainly be done with lyrics. There could be collaborative software for lyrics similar to Lotus Notes.

Eventually, some changes could percolate up into the groups own versions of songs. The data thus gathered could also cause the group to present songs differently in different venues, depending on the feedback of people from that geographical area.

Perhaps the process could advance to the point where a group of online users would not need to start with a musical group at all, but could create their own music according to their own taste. Obviously, the creation process would be much aided by software trying to fashion a desirable song. Perhaps people could start with templates of traditional songs not protected by copyrights. Once a desirable song had been created that was enjoyed by enough people in a particular part of the country, a group of actual musicians could learn the song and go perform it there for them.