(Any chance of getting hold of and trying an older version of the converter?)

The error is only visible (in the command prompt window) if you run the comand line version of the tool (POF2JED.exe) . It's not visible in the GUI version (WinPOF2JED), and it's not ncluded in the log output that gets written to the conversion .txt file.

Both versions produce the same JEDEC file, and so I guess if this issue is real, they both suffer from it.

There is a way to enable a detailed debug log to be generated from the command line version, and that suggests a problem right at the end of the POF file, where it tries to read the global clock bits, the JTAG bit and the User ID bits.

(and it seems to only happen when the 128-macro cell part is used)

Sorry Ed, I'm not aware any links to an older version.

Dave

That's kind of scary, that if there is a potential issue with the JED file, the windows tool is keeping quiet about it.

Sorry to revive an old thread, but I have just had a concrete instance of this problem. To be precise, I have a POF file, created from Verilog source using the Quartus 13.0-sp1 toolchain, which I can blow onto an EPM7128SLC84 obtained from ebay which works as expected. If however I run the POF file through pof2jed and blow the resulting JEDEC file onto an ATF1508AS, it doesn't quite work as expected. From the behaviour I reckon there are two differences in the actual logic implementation.

Does anyone here have any further information about this problem? What do people round here use to program their ATF1508's?

Do you think you could post your Verilog source? I'm interested to understand what features of the design provokes the failure.

I think it might be connected with more complex use of clocks (i.e. a design that uses multiple clocks, or needs the clock inverting). From what I recall, the POF2JED tool was not correctly mapping the configuration of the global clock mux.

Dave

Yes, I can post the Verilog code. It's in the attached zip file. There are 3 Quartus projects in there - Test0, Test1 and Test2. Test0 is for the ATF1502, Test1 for the 1504 and Test2 for the 1508. They are intended to run on this board:

https://www.microchip.com/developmentto ... 15XX-DK3-U

These projects were produced to meet several aims - to help me get familiar with CPLDs and Verilog, to get some idea of how much stuff you can fit in one of these chips, to validate the programming setup and to test chips obtained from sources such as ebay.
The Test0 and Test1 projects work with no issues.
The Test2 project was not so fortunate. Basically the project consists of the following:

The system clock (2MHz on that board) is fed through three prescalers - first by 625 (down to 640Hz), second by 32 (down to 20Hz), third by a variable ratio from 1 to 16. The third prescaler output is fed to a two-digit BCD up/down counter. The board has 4 7-segment displays driven by 4 bit binary to 7-segment decoder modules, with each BCD digit driving two displays.
The push buttons are used as follows:
SW1 - changes between up and down counting
SW2 - increases prescaler 3 ratio (reduces count rate)
SW3 - decreases prescaler 3 ratio (increases count rate)
SW8 - pauses the count for as long as it is held
SW7 - switches the display between the BCD counter output and the prescaler 3 ratio and count.

What I found was that it all works on an EPM7128 device. If I use pof2jed and run the output on an ATF1508 I observe the following behaviour:

1. 7 segment display 3 displays the digit 2 incorrectly - the F segment is illuminated when it should not be. All other digits and all other displays work correctly.
2. When counting down, everything works correctly. When counting up, if the most significant digit is even it never changes; if it is odd, it increments when the least significant digit rolls over from 9 to 0, as expected.

There is only one clock in the system - the 2MHz clock provided by the on board xtal oscillator. Internally a low frequency clock is used to clock some stages, but that clock is obtained by dividing down the original 2MHz so there shouldn't be any timing or metastability issues.
The buttons drive the asynchronous reset pins of flip-flops used to implement debouncers.

This actually makes those issues more likely.
Let's say you have two flip-flops, with the output of A connected to the input of B, and both using the same clock. A's output will change slightly later than the clock edge, and by then B will have loaded A's previous output.
If B is using a derived clock, then its edges will come slightly after the one used by A. A's output might have already changed by the time B sees its clock edge. Or it might change later. Or it might change during the edge. You have no control over that.
Unless you must use multiple clocks (for example, you have an external device that provides one for communication), it's best to use one clock everywhere. Use the flip-flop's clock enable input to control when it loads.

BTW, welcome! It might be best to start a new thread to introduce us to your project and your current difficulty (if it still stands.) And then of course we also have the Introduce Yourself thread.

Another issue is that, even if I can get past this POF2JED problem, you have to start with a solution which fits on the EPM7128. Reading the data sheets, it seems that the ATF1508 has significantly increased functionality compared to the EPM7128, and lots of things which fit on the former won't fit on the latter. For example the 1508 has independent output enable lines on all I/O pins whereas the 7128 can only have 6 OE signals. You could implement a 6521/6821-style PIA on a 1508 with independent direction control of each line on a 1508, but not on a 7128. Also, the 1508 can, in some situations, use the flip flop in each macrocell independently of the I/O pin associated with it - the I/O can be driven by a combinatorial output while using the flipflop for buried logic.

I've been playing around with CUPL a bit since the first post. Wincupl is a hideous thing, with lots of crashes, although some can be avoided by using cupl.exe and find1508.exe from the command line rather than using the IDE. The CUPL language itself is horrible. It's very unpredictable - you never quite know what it is going to make of any particular construct. You can't use another macro from within a macro definition, which makes it quite hard to produce modular designs. In some cases the minimiser can crash if you use the maximum optimization mode (-m4).

One thought I have had is to use yosys to digest the verilog files and transform them into RTL. Then it might be possible to write a script which transforms the RTL into very simple CUPL code with no indexed variables or macros (the things which cause the unpredictable behaviour) and run that through the command line cupl compiler and fitter. Maybe that way I'll be able to use Verilog to program the 1508. Not much progress on this front so far, however.