If we follow “An introduction to reconfigurable computing”, there are four different levels of reconfiguration in hardware.
1. reconfigurable functional units within a host processor
2. reconfigurable unit as coprocessor
3. an attached reconfigurable processing unit as an additional processor in a multi-processor system
4. an external standalone processing unit which is the most loosely coupled form and hooks to the system through IO interface.
Obviously above is from processor point of view. In SoC design, it is very common to use hardware logics to implement a signal processing chain which may consists of multiple processing units. Many cases we’d like to be able to reconfigure the processing chain so that it handles different signal sources (module that sends data into processing chain), signal sinks (module that receives data from processing chain), and signal processing units (module that processes data).
In this article, we discuss this type of reconfiguration to recondition processing chain. First there are two types of data sources. Type A sends out data valid strobe with data so it is a data push. Type B receives data valid strobe and responds with correct data so it is a data pull/read.
The mux on type B data source is important since it facilitates reconfigurability. As will seen, this kind of mux can be on data or on strobe for data sinks and processing units. Processor (firmware) programs these muxes’ select signals to reconfigure the processing chain. This also implies that the relationship of data valid strobe and data should be the same across data sources, sinks, and PUs. In other words, the interface handshaking should be the same. One way to do it is data can come in the cycle after valid strobe.
There are also two kinds of data sinks. Type A receives both data valid strobe and data so it is a data push. Type B sends out data valid strobe and receives data correspondingly so it is a data pull/read.
Now let’s take a look of processing unit (PU). There are four types.
You can purchase points of this author. You have 0 points and this post costs 4 points.
At first sight, reconfigurable is a bunch of muxes that can be controlled by software or hardware. But once you really design it, you will see issues like data is pushed in or pulled out (in other words, who initiates transaction), data rate/clock rate is matched, how to implement self test, etc.
This article is very practical. It tells you how to design reconfigurable hardware that can be used in real system.
Thanks ckegley. Yes the article reflects real design that works in field. Let us know any question about this topic.