Dr Jefyll wrote:
MichaelM wrote:
I don't think that Xilinx has released the particular details of how the initialization of the BRAMs is mapped into the bit stream so that a user can write their own utility for this purpose.
I've done enough reverse engineering that, to me, it seems reasonable to adopt this approach whether Xilinx has released the doc or not. But I'm not volunteering. And admittedly the effort might not be worthwhile, balanced against whatever the next-best alternative seems to be.
Xilinx makes some nice tools for doing just this, i.e. patching the contents of their BRAMs, and the thread I linked to relates how EEyE and I used that tool to quickly change the memory contents before reprogramming the FPGA using either direct programming via JTAG or the configuration serial EEPROM. The structure of the FPGA, the location in the bitstream, and the organization of the BRAM makes reverse engineering this proprietary data structure a bit daunting, particularly since they provide the tools for free.
Dr Jefyll wrote:
MichaelM wrote:
The outputs of the FPGA will float, and for a brief time, between the completion of the configuration image load and the transfer of control to the new user application, may exhibit unreliable logic levels.
Doesn't the chip always configure upon powerup, and don't the levels also float then? IOW, isn't this an issue you face in any case?
You are absolutely correct that the Xilinx, Altera, and Microsemi RAM-based FPGAs all exhibit this behavior. I am simply pointing out to other readers that dealing with these reconfigurable parts requires some attention to the bitstream options and the external circuits. Therefore, if the interfaces for circuits external to the FPGA are not designed appropriately, then there may be some erratic behavior from both the FPGA and the external circuits. At least with Xilinx FPGAs, there are a number of bitstream options that can be used to reduce/eliminate open/floating pins, erratic output signals and incorrect state machine initialization. I always enable the Pull-ups during configuration option, and I always drive the DONE pin high after configuration is fully complete. The normally selected options for the bit stream generator do not select the options that I recommend. In particular, DONE is released high before the outputs are enabled and internal reset is released. These default configuration options can cause the state machines within the FPGA to misbehave if floating pins from the FPGA to external circuits cause those circuits to oscillate or otherwise behave erratically. The potential for metastability issues on inputs is somewhat elevated during this narrow time window as the FPGA switches from its internal configuration clock to a user clock.
Dr Jefyll wrote:
MichaelM wrote:
The 32 kb required to program the microprogram memories is a far cry from the nearly 1.2 Mb required to program the entire FPGA.
Memory is cheap. I don't see an issue with wasting almost 1.2MB if that'll achieve the goal. You mentioned a partial reconfiguration capability, but I don't see any great advantage. Maybe I'm missing something. I will say it seems a little backward to put multiplexers on the configuration memory so it can be written in-circuit.
The point I was trying to make was that the microprogram memory requirements are only a fraction of those of the full configuration image. Unless there is a significant change in the RTL of the FPGA design, it may be better to simply reprogram the microprogram memory with a 32kB image. Both the standard configuration image and any "user-defined" microprogram images would be stored in the same serial configuration memory. After configuration, at least with most Xilinx FPGAs, the pins used for reading the configuration image from an external serial (or parallel) EPROM revert to user defined I/O pins. In the case of the
M16C5x,
M65C02, and
M65C02A soft-microprocessor demonstration projects, the SPI Master peripheral is connected to the configuration memory. This allows the configuration memory to be reprogrammed in circuit using whatever files transfer program the user wants to use.
For me a WCS provides several options: (1) patching/fixing existing instructions without modifying the configuration image; (2) adding instructions to the existing instruction set of a microprogrammed processor core; and (3) replacing the microprogram in an existing microprogrammed processor core in order to implement a completely different machine. In the first case, it may be more reliable, but maybe less fun
, to simply replace the configuration image with a new image which simply contains the patched microprogram ROMs. It will certainly be much faster to boot with a patched image than it would be to boot and then using a subroutine, load the microprogram patches into a WCS. The same reasoning applies to the second option, but with a WCS it may be possible to dynamically load application-specific microprogram sequences. Using the WCS in this way, a standard instruction set could potentially be changed to implement digital filters instructions, graphics primitives, etc. which operate at the speed of the microprogram controller of the soft-core.
The third option provides a way to change a 6502 into a 65C02 or even a completely different microprocessor like a 6809 or 68HC11. The ALU of the M65C02A is fairly flexible and capable, but it only has six addressable registers: A, X, Y, P (6 bits), OP1 and OP2. OP1 and OP2 are working registers for holding the operands of an instruction. Therefore, as it sits today the internal microarchitecture of the M65C02A is unlikely to be useful as an implementation of another microprocessor, but it could be used to implement an application-specific or special purpose processor by replacing the contents of the microprogram ROMs.
Dr Jefyll wrote:
MichaelM wrote:
On a historical note, I recently went on a buying spree and bought several PDP 11 backplanes, processor cards, and memory cards
Sw-eet!!
But will you have time to play with all your toys?
Probably not as much as I'd like.
Something about putting food on the table and paying the mortgage. One reason I'm trying to wrap up the M65C02A on my
Chameleon Arduino-compatible FPGA Board as soon as possible is to use it to implement some peripherals for those PDP-11 processor cards. There is apparently a way to boot the PDP-11 processor cards using a serial interface. I am looking forward to completing the M65C02A and using the two serial ports and the remainder of the large Serial Configuration EPROM to implement a TU58 tape unit which interfaces to the PDP-11 using a serial port.