Optimizing Routing Architectures for Small-Scale Heterogeneous Systems

Abstract

Dette arbeidet hadde som mål å finne en arkitektur for ruting av en liten FPGA integrert ved en MCU, basert på spesifikasjoner gitt av Microchip Technology. Designet måtte passe med MUX-baserte teknologier, uten noe form for tri-state bufring. Designet måtte være skalerbart til en hvis grad, den måtte kunne rute de fleste design og måtte være areal-effektivt med hensyn til antall MUX2 porter. Dette arbeidet så på 2 forskjellige arkitekturer, det vil si route-through og bus-arkitekturen. For å kunne evaluere de forskjellige arkitekturene, så ble det benyttet 5 forskjellige Verilog test design (AND4, ADD2, SR4, SR8 og SR15), i tillegg til en kost-estimator, samt en prosentverdi for estimert route-through og logikk utnyttelse av arkitekturen. Resultatene viste at route-through arkitekturen kunne rute de fleste design med en størrelse på (4, 8), med 7 INTRA ledninger og 4 INTER ledninger per tile. Arkitekturen hadde ca 6x så stor kostnad som den forrige arkitekturen fra Microchip. Bus-arkitekturen klarte ikke å rute noen design, med en kostnad ca 4x så stor som den forrige arkitekturen fra Microchip. De fleste testene gjennomført på route-through arkitekturen hadde en høyere prosentandel logikk utnyttelse for en størrelse på (4, 8), samt en høyere prosentandel route-through utnyttelse for størrelsen (8, 4). Noen tester funket ikke for størrelsen (8, 4), gitt manglende antall innganger. Dette arbeidet har også sett på forholdet mellom INTRA og INTER parameterene for route-through arkitekturen. Resultatene viste en 37% variasjon i total mengde plasserte blokker for forskjellige tester, primert for størrelsen (4, 8). Spørsmålet om enten antall plasseringer eller rute-ressurser ble brukt opp først var også diskutert, hvor ideelt sett så burde antall plasseringer bli brukt opp først. Flere observasjoner ble gjort under dette arbeidet som burde være et tema for videre forskning. Sporadiske routing-løkke feil kan bli unngått ved bruk av et form for automatisert test skript. Videre utvikling kan også ta nytte av å bruke et annet PnR verktøy, med en potensielt funkende GUI. En ny måleverdi for blokker som har både route-through og logikk funksjonalitet kan være nytting for å få mere innsikt i tilfeller av kongestion av rute-ressurser. Ytterligere observasjoner ble gjort i forhold til PWR blokker og enhetsklokken.

This work aimed to find a routing architecture for a small FPGA integrated alongside an MCU, based on specifications given by Microchip Technology. The design needed to fit MUX-based technologies, with no tri-state buffers. It needed to be scalable to some degree, could route most designs (within reason), and needed to be area efficient (regarding the number of MUX2 gates). This work looked at 2 different routing architectures, namely the route-through and bus architecture. In order to evaluate these architectures, then 5 different Verilog test designs were used (i.e., AND4, ADD2, SR4, SR8 and SR15), with the addition of a cost estimation metric, as well as an estimated route-through and logic utilization percentage of the architecture. The results showed that the route-through architecture could route all test designs with a grid size of (4, 8), with 7 INTRA wires and 4 INTER wires per tile. The architecture had around 6x the cost of previous architecture used by Microchip. The bus architecture failed to route any design, with a cost around 4x times that of the previous architecture used by Microchip. Most of the tests performed on the route-through architecture had a higher percentage of logic utilization for a grid size of (4, 8), and a higher percentage of route-through utilization for a grid size of (8, 4). Some tests did not work for a grid size of (8, 4) due to a lack of sufficient amount of inputs. This work also looked at the relationship between the INTRA and INTER parameters for the route-through architecture. The results showed a 37% variation in the total amount of placed blocks for the various tests, primarily for a grid size of (4, 8). The question of whether block placements or routing resources run out first on the device was also discussed, where ideally, block placement should be the factor that runs out first. Several observations were made that warrant further study. Occasional routing loop errors could be mitigated by the use of automated test scripts. Further development might also benefit from using a different PnR tool, with potentially a working GUI. A new metric for blocks that have both route-through and logic functionality could help gain more insight into routing congestion issues. Additional observations were made in terms of the PWR block and device clock.