Electronics > FPGA

Programming (non-JTAG) MAX7000 devices

<< < (34/35) > >>

You don't need an x86 machine to run DOSBox. What I'm suggesting is to build a Raspberry Pi version, where you would be able to manipulate GPIOs relatively easily (i.e. using this https://abyz.me.uk/rpi/pigpio/cif.html)

A quick update.

I spent a few hours playing with my Arduino based "programmer".

I worked with the EPM7032V, the 3.3V device from which I had been able to unload the device ID. I have had some success writing zeroes to blocks 0,1 and 2, but other blocks remained stubbornly all ones (blank). I was able to erase the device only after multiple attempts to do the erase sequence. During this session I was unable to erase. I started to look at the signals using my Rigol scope. Many signals did not look clean, and Vcc was particularly "nasty". This could be explained by the use of a breadboard and longish connection wires, coupled with a less than perfect ground for the Vss pins. I am driving inputs using the output from the 5V Arduino Mega 2560. Since this is a CMOS device the outputs swing more or less rail to rail (0 -> 5V). Although I was driving the 7032V inputs via 1k resistors, I did not see the inputs clamping to a little over Vcc. This might also have contributed to the flaky behaviour. So I am giving up on this until I get a new breakout PCB made (my first was a bust). BTW when I erased this device, block 0x7C was also erased to all ones, and I was unable to re-program it. I will re-visit when I have the new PCB and I will use proper level translator ICs (74LVC8T245).

Note: many devices have clamping diodes on the input and output pins, possibly there for ESD reasons to catch spikes. With care you can drive 3.3V inputs (which have clamps) from a 5V driver, as long as you limit the current using a resistor. The RC network of resistor and input capacitance will impact slew rate, but for many inputs this is not an issue.

So I swapped over to one of the 5V devices. Vcc in the Arduino sketch was changed to 5V. I ran the code not really expecting it to work, but blow me down, I saw the device ID of ALTERA92 appear. I have no idea why it is now working. The operation of programming was more robust in that it took only one try to program a block and any block I chose appeared to program to zeroes. I tried erase. It didn't work, so I re-tried. This time it worked and what's more the block 0x7C was programmed correctly, but with the wrong device ID, since the sketch still contained the ALTERA93 device ID for the 3.3V device. TBH I'm a little surprised that not only is it working, but it seems much much less flaky.

Great! So the last missing piece is POF to raw shift data conversion. One idea: you can turn your DOSBox-based emulator into converter: track the SDINx shifting, output the last shifted data together with an address when you see an NTPW pulse with SBI=1, capture entire POF this way, then send it block by block to Arduino by some other way (not from DOSBox C code, i.e. via terminal or Python script or whatever), implementing shifting and NTPW pulsing in the Arduino.

Upd: found a general (nothing device-specific there) POF format description: http://ftp.dataio.com/main/manuals/unifam/translation%20formats.pdf (page 10)


--- Quote from: abyrvalg on September 14, 2022, 06:51:58 pm ---Upd: found a general (nothing device-specific there) POF format description: http://ftp.dataio.com/main/manuals/unifam/translation%20formats.pdf (page 10)

--- End quote ---

Yep. I found this a few weeks ago. I made a post on 21st Aug with an attachment of Perl code (I had to give it the .BAS extension in order to upload) to decode Altera POF. This document was a very helpful reference.

The format is actually very simple, it's just repeated blocks of: tag (16 bits); length (32 bits); block of "length" bytes. Some of the blocks of bytes are in simple ASCII format. The largest block with tag 17 (0x11) is the one which contains the data to be programmed. I am pretty sure that the first 'n' bytes (n=12?) of this data block are a (sub)header and do not form part of the data to be programmed. The tags for the ASCII part of the POF can vary in length. In a different posting I looked at the length of the program data tag block and noted that the length differed depending on which version of the EPM7032 you were compiling for. This unfortunately confirmed that I could not used Quartus V13 on my PC to compile Verilog for the MAX7000 devices which triggered the whole project.

When the ALL03 EXE loads any POF, it relocates the data block into a fixed location in memory, and modifies the ASCII data on these type of tags, such that the binary program block is always found at a fixed address in the buffer. This is helpful when looking at CPU trace files, as the reads from this data section can be more easily filtered. Using trace files of CPU operations gives one possible way to determine the mapping, however the trace files get pretty big quickly (Gb++). It may be possible to hack the code to only write out reads/writes in a particular range, or this might even be already supported, IDK. Data reads from the buffer to form the 2 x 80 bit serial stream for SDINA and SDINB are not consecutive.

A script simulating raw to POF conversion as done by AMAX70.exe during read (all those bit tables are ripped from exe).
The output is not a full POF, just the data block as seen by exe. The programming function appears to be doing a reverse mapping using same tables.
A "row" in script's terminology is a full content of a single address (all SDINx-SDOUTx chains together, 2x80 bits), while a "plane" is an array connected to a single SDIN-SDOUT.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod