The following points are criticisms of the Warren Approach made in an email from an industrial researcher at a large USA electronics company. After each comment there is a response from DJ Greaves.
>Interesting research project. Not suitable for commercial deployment. > >Processors are dirt cheap, and getting cheaper. If you were building in >volume, you'd do a standard cell part (that Xilinx 4010 isn't cheap), and the >processor and memory would come 'for free'. So what's the point of 'no >processor'?
The FPGAs that we have are only for development. The Warren approach is intended to be licensed as macrocells for inclusion in the custom ASICs of other manufacturers, such as those who make video cameras, televisions and CD players.
I agree that processors are cheap now. However, with the Warren approach, an ATM interface can be the same cost as the standard ports found on devices, such as IR, SPDIF and Serial ports. This work is targeted at consumer devices where no additional cost can be tolerated.
>If there's no processor, how do you do manufacturing and power-on diagnostic >testing? How does it do ABR? How do you manipulate traffic contract >parameters and the corresponding shapers and policers? How do you handle >loopback, AIS/RDI and PM cells? How do you perform functional upgrades and >bug fixes (or do you propose to keep that FPGA)?
Existing microprocessors found in products remain. They may perform all of their current jobs, including testing and user interface. However, they do not have to become 32 bit processors running hundreds of kilobytes of additional code. Eight-bit processors running out of masked prom suffice, and these will not have to be reprogrammed each time ATM standards change.
If ABR (available bit rate) is required, which is not for all types of device, then this is actually quite easy to implement in hardware for a small number of VCIs (virtual circuit identifiers). Infact, a hardware timer that spaces cells is easier to use that a real-time software solution. The timer rate may easily be set in hardware from the RM (resource management) cells received.
Traffic parameters for an end device are known by looking up in a device id table. Each Warren device has some information stored about it in tables on the Warren controller. This includes the VCIs and data rates that the device generates or receives.
Shaping and policing can be placed in home switches if desired. The Warren approach does not prohibit arbitrary complex switches. On the other hand, it does allow switches to be very simple, and even busses and rings can be used as distributed switches.
Generation and loopback of AIS (alarm indication signal) and RDI (remote defect indication) cells is handled within the 2000 gates or so required for a Warren device. The Warren control protocol requires that the data paths to support these cells exist and is essentially the same.
I have implemented full I.610 PM (performance monitoring) in hardware for other projects and it takes several thousand gates. I would not advocate it for cheap home devices.
Functional upgrades and bug fixes are not envisaged. The idea is that devices are simple. For instance, the Warren Phone is an exact equivalent to a standard POTS (plain old telephone service) phone in all of its ringing, dialing and audio semantics and the POTS interface has stood the test of time for more than half a century.
>If the Warren controller is in the public network, how does it do CAC without >knowing too much about the peculiarities of buffering and scheduling in the >Warren switch? Is sucking intelligence out of the user's home and into the >public network in the user's best interest (historically, this has not been >the case)?
The idea is that the controller knows everything about all of the devices it controls, including the buffering amounts and styles used in each switch. A Warren itself may consist of a variety of different types of switches provided the controller recognises the type identifier of the switch (or can look it up somewhere, such as on the web). Therefore the controller is able to perform the CAC (call admission control). There is a pair of alternatives for the location of the Warren Controller: in the first, the controller is outside of the home. This appeals to Telcos and is suitable where the home network is minimal. The second alternative is where the controller is owned by the householder. This is suitable for larger home area networks. We are working on software control systems which will allow remote diagnostic services for the home network without revealing home secrets.
>In another words, you're optimizing around the wrong things. > >Note that at the other extreme, Microsoft is proposing to make the PC or WinCE >STB into the switch.
We know about Microsoft - we have recently welcomed a large Microsoft presence here in Cambridge. However, there is always room for a lower cost solution.