Fine grain vs. Coarse Grain Architectures

Now that sounds like homework assignment right?

Depends on whether you work for a company that provides devices with a coarse- or fine-grain architecture.

-a

That is the problem. It is so simple that there is not a direct answer. So if you do not know, don=B4t tell me that it is a joke. Don=B4t lost your time. I would like to choose a strategy to implement a dynamic partially reconfigurable architecture, but I think that the first thing to decide is, what granularity it should have. I have read many articles about both strategies, but anyone tells a definitive assertion about it. What benefits can I enjoy using fine-grain against coarse-grain and vice-versa?

I don't think this is the first thing to decide on at all.

I suggest going back thinking about why you want to do dynamic reconfiguation....

Which applications do you think you can improve by the technique?

Are your computations suited to coarse-grained logic (in which case, you might be better off with a general purpose processor) or is it something like multimedia or crypto, or other operations that aren't particularly efficient on general purpose processors?

To what extent do you need to reconfigure your system? Is it just specialising your logic for particular values, or do you need to to change the purpose of the logic at each reconfiguration? Also, how much compute power do you have to manage reconfiguration?

As 'cool' as partial dynamic reconfiguration might be, it's hard to do something that's actually useful. The clearer you are on the specifics of what you are *trying* to do, the easier it will be to make something useful. It's probably better for you to have something that works very well on one particular application, than something that's not very good on a wide variety of applications.

For example, consider the work they did at Glasgow Univ. on the topic. As far as I remember, they were very specific in terms of the optimisations they were trying.

Martin

easier to fit

versus Coarse Grain easier to route

-- Mike Treseler