Sylvain Munaut on implementing E1 using an FPGA and not much else. This is interesting to me because of the amount of hardware around, PABXs and exchange equipment, that uses this stuff must be enormous.
At 8 mins 50 secs Sylvain shows the architecture of this design, which is basically a SoC with DMA channels and a RISC core and a USB subsystem and an E1 subsystem.
Here is a suggestion for a project for anyone interested in advanced systems development. Instead of programming logic to implement a CPU running software programs, design a system which takes a certain specification of what to do with E1 and USB events, and then compiles that specification into a low-level description of what bit-stream to send to the FPGA flash storage, which will cause the FPGA to be programmed to carry out those actions in hardware, without running a program stored in memory. It might be easier than it sounds! 😂 See Amazing Shit You Can Do With Cheap FPGAs and Open Source Hardware Designs.
The idea I have in mind is to use a hardware equivalent of these functional programming units which compile assembly language code: Writing Assembler Using Standard ML. So you would build up a kind of toolbox of functional descriptions of abstract circuits with interfaces that can be "plugged together" to produce particular concrete circuits on the FPGA, and that process of computing the bit stream that will become the actual FPGA configuration will be determined by the program which consists of a series of these functor applications applied in a hierarchical structure, the result of which will be a functional program which computes the tile allocations and the interconnections, and generates the bitstream of the FPGA program.
To give some idea of the kinds of functors you would develop which can be plugged together: one could be a functor which implements a USB "transmit frame" in response to the rising edge of a line on a notional bus, which has an eight-bit buffer address, identifying the block of SRAM that contains the frame octets, the first two of which are the packet length, say. This in turn would be composed of simpler primitives, such as a functor which defines a circuit which has parameters identifying an SRAM page, and a 16 bit register, and which loads two octets from the start of the frame in the given page into the register, and another which, given a certain 16 bit address register identifier as a parameter, reads a certain page of SRAM and loads two octets from the offset given by the address register into a destination register and raises a signal on a READY line identified by another parameter. Etc. Etc.
Then, to customise these functors to a specific type of FPGA, you have a lower-level set of functors which implement some FPGA-specific primitives. Then to retarget to a different type of FPGA, you write the glue functors which map the functors at the levels of registers, SRAM pages, etc, onto whatever primitives you have at the lower level which map directly to the FPGA hardware. The analog of this layer in my abstract assembler example is the GNU Lightning implementation which maps Lightning abstract assembler to the particular machine code of a given target processor. And then if you have a digital circuit simulator that you program in some language, you could use this same layer to write out a simulation, and at this level you could also define debugging instrumentation which could be turned off for production.
At 8 mins 50 secs Sylvain shows the architecture of this design, which is basically a SoC with DMA channels and a RISC core and a USB subsystem and an E1 subsystem.
Here is a suggestion for a project for anyone interested in advanced systems development. Instead of programming logic to implement a CPU running software programs, design a system which takes a certain specification of what to do with E1 and USB events, and then compiles that specification into a low-level description of what bit-stream to send to the FPGA flash storage, which will cause the FPGA to be programmed to carry out those actions in hardware, without running a program stored in memory. It might be easier than it sounds! 😂 See Amazing Shit You Can Do With Cheap FPGAs and Open Source Hardware Designs.
The idea I have in mind is to use a hardware equivalent of these functional programming units which compile assembly language code: Writing Assembler Using Standard ML. So you would build up a kind of toolbox of functional descriptions of abstract circuits with interfaces that can be "plugged together" to produce particular concrete circuits on the FPGA, and that process of computing the bit stream that will become the actual FPGA configuration will be determined by the program which consists of a series of these functor applications applied in a hierarchical structure, the result of which will be a functional program which computes the tile allocations and the interconnections, and generates the bitstream of the FPGA program.
To give some idea of the kinds of functors you would develop which can be plugged together: one could be a functor which implements a USB "transmit frame" in response to the rising edge of a line on a notional bus, which has an eight-bit buffer address, identifying the block of SRAM that contains the frame octets, the first two of which are the packet length, say. This in turn would be composed of simpler primitives, such as a functor which defines a circuit which has parameters identifying an SRAM page, and a 16 bit register, and which loads two octets from the start of the frame in the given page into the register, and another which, given a certain 16 bit address register identifier as a parameter, reads a certain page of SRAM and loads two octets from the offset given by the address register into a destination register and raises a signal on a READY line identified by another parameter. Etc. Etc.
Then, to customise these functors to a specific type of FPGA, you have a lower-level set of functors which implement some FPGA-specific primitives. Then to retarget to a different type of FPGA, you write the glue functors which map the functors at the levels of registers, SRAM pages, etc, onto whatever primitives you have at the lower level which map directly to the FPGA hardware. The analog of this layer in my abstract assembler example is the GNU Lightning implementation which maps Lightning abstract assembler to the particular machine code of a given target processor. And then if you have a digital circuit simulator that you program in some language, you could use this same layer to write out a simulation, and at this level you could also define debugging instrumentation which could be turned off for production.
No comments:
Post a Comment