FAILURE OF ABSTRACTIONS AND THE DETAILS PROBLEM WITH FPGA/SOC
Much of the environment to develop with FPGA and SOC provides abstractions that present a straightforward and relatively easy to grasp means of dealing with the devices, but they are not perfect abstractions which from time to time requires the user to plummet to the stygian depths of minutia. These diversions come up suddenly.
At the first level, we design logic for FPGA and SOC using high level hardware description languages, such as VHDL or Verilog. The actuality of the FPGA chips is many replicated tiles of look up tables, multiplexors, PLLs and clock modules, RAM units, and a byzantine distribution system for both general and clock signals.
The toolchain synthesizes the HDL into logical schemes and then places the logic onto specific tiles on the chip. It routes all the signals and validates a myriad of rules for their placement and interaction. At the end it generates a bitstream file which is shifted into the chip so that the relevant bits control the function of each tile and signal router. Mostly this happens invisibly, thanks to the abstractions.
The challenge comes when errors arise which are presented as a violation of those inner rules and construction details. With Vivado I received errors about challenges routing clock signals. At the HDL level, I specified clocks and used those in logic. Suddenly I had to know exactly what was the chip's switching matrix for clock signals, which tiles held various clock and buffer functions, and the way these are configured based on my HDL.
That failure of abstraction leads to hours of study of trivia and specific chip details - a kind of light years big leap from HDL to chip structure. It makes the errors a bit incomprehensible and introduces a long learning curve delay at random moments within a project.
With Qsys, we also have a tool that abstracts and eases the configuration and interconnection of IP to form the system desired. However, there are those hundreds of very detailed parameters and timings that are needed, the polar opposite on the spectrum from abstraction to bloody detail.
In my last post I mentioned that so many hobbyists seemed to lean on the crutch of reference designs, copying and pasting, rather than using any guide that steers one to the logic behind the parameters for the specific board, chip and design project.
PRESETS AND REFERENCE DESIGNS - A SOLUTION TO WILDLY VARYING COMPLEXITIES
I did find that Qsys comes with preset files for various boards containing the Cyclone SOC chip, allowing a user to select that preset and have all the parameters appropriate to the board's implementation be populated into the design.
Thus, the user can grab a preset file, just like they can open a reference example file and grab parameter values, avoiding the need to understand any of the depths behind those values. Alas, in FPGA land the potential remains that some situation crops up that requires different settings, plunging the user down to the abyss of hardware details.
Alas, not every board maker has provided a preset file or Intel have chosen not to share every one. Further, cases will arise where one needs different values, but these necessitate a trip to into the abyss of gritty hardware details.
PRACTICAL SOLUTIONS EXIST BUT QUANTUM LEAPS TO THE ABYSS LURK
I can imagine a world where the stride is not so extreme - where there exists a stairstep of abstractions or explanations where one can avoid the leap into the basement and face a lesser learning curve and less extensive set of issues to address. I imagine a world where linkages are suggested to guide one from known references to handle portions of the parameters.
For example, the datasheet for the specific DRAM chips on a board contain some of the parameters required in Qsys, but others depend on the murky IP wrapped around it that designs clocking structures, buffers and the like which also require parameterization in Qsys. Rant off for now, on to the project.
No comments:
Post a Comment