What is required to target a new device?

Question

From a high-level point of view, what is required to target a new device with Yosys? I'd like to target a Xilinx XC9572XL. I have one these development boards: XC9572XL-CPLD-development-board-v1b. The architecture of this CPLD is fairly well covered in the Xilinx documentation here.

I think I need to do the following:

1. Work out how to get Yosys to synthesise a design to a Sum-of-Product and D-type Flip Flop based netlist.
2. Output that netlist as a BLIF format from Yosys.
3. Create a 'fitter' (analogous to arachne-pnr for the ICE40 FPGA) for the XC9572XL
4. Output a JEDEC file with the appropriate fuses that need to be set to implement the design in the previous step.
5. Flash the design to the CPLD using xc3sprog.

It looks possible. The hard bit is building a 'fitter' tool. This tool needs to understand the CPLD's resources and then needs some clever algorithms to fit the design and output the required fuses in a JEDEC format. One import missing piece is the mapping between the 'fuses' in the physical CPLD and the fuses in the JEDEC file. This would have to be reverse engineered. I note that a JEDEC file from Xilinx WebPACK ISE contains 46656 fuses. Each of those map back to some configurable node in the CPLD.

I'd like to know what others think about this approach. What types of issues am I likely to encounter?

What legal aspects do I need to consider if I was to undertake this? Should I write to Xilinx first and seek permission from them should I decide I want to reverse engineer a JEDEC file produced by their tool?

The XC9572XL is an obsolete part...

Answer 1

1. Work out how to get Yosys to synthesise a design to a Sum-of-Product and D-type Flip Flop based netlist.
2. Output that netlist as a BLIF format from Yosys.

You can do two-level synthesis with ABC from a logic-level BLIF file. For example:

$ yosys -p synth -o test.blif tests/simple/fiedler-cooley.v
$ yosys-abc
abc> read_blif test.blif
abc> collapse
abc> write_pla test.pla

Now you can aim for writing a program that converts a .pla file (plus auxiliary information that might be generated by a yosys plugin you'd need to write) to a JEDEC file.

What legal aspects do I need to consider if I was to undertake this?

IANAL. TINLA.

When you reverse engineer it by analyzing the software provided by the chip vendor: In this case it really depends on the country you are living in. For example, in europe you can reverse-engineer, even disassemble, software in certain situations, even when the software EULA prohibits it. I explain this in a bit more depth here.

I think reverse engineering the silicon itself (instead of analyzing the software) is less problematic in places like north america.

Answer 2

Have you considered targeting the CoolRunner-II family? I did some fairly extensive RE on it (https://recon.cx/2015/slides/recon2015-18-andrew-zonenberg-From-Silicon-to-Compiler.pdf) and understand the majority of the bitstream format. Porting Yosys to it is high on my priority list once I figure out the last of the clock network structure.

These devices are more recent and lower power, plus the internal architecture is cleaner and easier to target (nice regular AND/OR array vs having some pterms dedicated to certain OR terms).

In either case please contact me to discuss further, I'd love to collaborate.

EDIT: Clifford is right, reversing silicon is explicitly legal in the US (17 USC 906) while software is more of a gray area. ISE is also such a giant monster that nobody with their head screwed on right would want to reverse engineer it; the chip is a lot easier to follow.

Although the XC9500XL series is an older 350nm family (less metal layers, larger features, easier to see detail under a microscope) it also uses a lot of nasty analog tricks with floating gate EEPROM/flash cells directly in the logic and sense amplifiers on the output. CoolRunner-II is 180nm with 4 or 5 metal layers depending on density, and the main logic array is entirely digital and a lot easier to reverse engineer.