• #### Implementing PLDs (PAL/GAL) into Verilog

From briccus@gmail.com@21:1/5 to All on Tue Aug 17 14:47:00 2021
Hi all,
I'm translating into Verilog some schematics.I have faced some PLDs (PAL or GAL),
Some have pure combinatorial logics which is easy to write in Verilog but other are registered so they need flip flops.I was wondering how to implement the latter.Here an example where you can see four outputs are registered so there is a clock (pin1 of
the PAL device) and a output enable (usually pin11 tied to GND)

/** Inputs **/
Pin 2 = i2;
Pin 3 = i3;
Pin 4 = i4;
Pin 5 = i5;
Pin 6 = i6;
Pin 7 = i7;
Pin 8 = i8;
Pin 9 = i9;
Pin 12 = i12;
Pin 13 = i13;
Pin 14 = i14;
Pin 15 = i15;
Pin 16 = i16;
Pin 17 = i17;
Pin 18 = i18;
Pin 19 = i19;

/** Outputs **/
Pin 12 = o12; /**(Combinatorial, Output feedback output, Active low) **/ Pin 13 = o13; /**(Combinatorial, Output feedback output, Active low) **/ Pin 14 = o14; /**(Registered, Output feedback registered, Active low) **/ Pin 15 = o15; /**(Registered, Output feedback registered, Active low) **/ Pin 16 = o16; /**(Registered, Output feedback registered, Active low) **/ Pin 17 = o17; /**(Registered, Output feedback registered, Active low) **/ Pin 18 = o18; /**(Combinatorial, Output feedback output, Active low) **/ Pin 19 = o19; /**(Combinatorial, Output feedback output, Active low) **/

/** Equations **/

!o12 = o13;
o12.oe = vcc;

!o13 = o17 & o18
# o16 & !o18 & !o19;
o13.oe = vcc;

!o14 .d !i2
# i2 & !i4 & o14
# i2 & i4 & !o14;
o14.oe = OE;

!o15 .d !i2
# i2 & !i4 & !i5 & !o14 & o15
# i2 & !i4 & i5 & o14 & o15
# i2 & i4 & !i5 & o14 & o15
# i2 & i4 & !o14 & !o15
# i2 & i5 & !o14 & !o15
# i2 & !i4 & !i5 & o14 & !o15
# i2 & i4 & i5 & o14 & !o15;
o15.oe = OE;

!o16 .d !i2
# i2 & !i5 & o15 & o16
# i2 & !i4 & !i5 & o14 & o16
# i2 & i5 & !o16
# i2 & i4 & !o15 & !o16
# i2 & !o14 & !o15 & !o16;
o16.oe = OE;

!o17 .d !i2
# i2 & !i3 & i6 & o17
# i2 & !i3 & o17
# i2 & !i5 & i6 & o17 & !o19
# i2 & i3 & i5 & !o17
# i2 & i3 & !i6 & !o17
# i2 & i3 & !o17 & o19
# i2 & !i6 & !o17 & o19;
o17.oe = OE;

!o18 = i3 & o17
# !i3 & !o17 & o19;

!o19 = !i4 & o15 & o16
# !i4 & o14 & o16;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Johann Klammer@21:1/5 to bri...@gmail.com on Wed Aug 18 09:45:24 2021
On 08/17/2021 11:47 PM, bri...@gmail.com wrote:
Hi all,
I'm translating into Verilog some schematics.I have faced some PLDs (PAL or GAL),
Some have pure combinatorial logics which is easy to write in Verilog but other are registered so they need flip flops.I was wondering how to implement the latter.Here an example where you can see four outputs are registered so there is a clock (pin1
of the PAL device) and a output enable (usually pin11 tied to GND)

/** Inputs **/
Pin 2 = i2;
Pin 3 = i3;
Pin 4 = i4;
Pin 5 = i5;
Pin 6 = i6;
Pin 7 = i7;
Pin 8 = i8;
Pin 9 = i9;
Pin 12 = i12;
Pin 13 = i13;
Pin 14 = i14;
Pin 15 = i15;
Pin 16 = i16;
Pin 17 = i17;
Pin 18 = i18;
Pin 19 = i19;

/** Outputs **/
Pin 12 = o12; /**(Combinatorial, Output feedback output, Active low) **/ Pin 13 = o13; /**(Combinatorial, Output feedback output, Active low) **/ Pin 14 = o14; /**(Registered, Output feedback registered, Active low) **/ Pin 15 = o15; /**(Registered, Output feedback registered, Active low) **/ Pin 16 = o16; /**(Registered, Output feedback registered, Active low) **/ Pin 17 = o17; /**(Registered, Output feedback registered, Active low) **/ Pin 18 = o18; /**(Combinatorial, Output feedback output, Active low) **/ Pin 19 = o19; /**(Combinatorial, Output feedback output, Active low) **/

/** Equations **/

!o12 = o13;
o12.oe = vcc;

!o13 = o17 & o18
# o16 & !o18 & !o19;
o13.oe = vcc;

!o14 .d !i2
# i2 & !i4 & o14
# i2 & i4 & !o14;
o14.oe = OE;

!o15 .d !i2
# i2 & !i4 & !i5 & !o14 & o15
# i2 & !i4 & i5 & o14 & o15
# i2 & i4 & !i5 & o14 & o15
# i2 & i4 & !o14 & !o15
# i2 & i5 & !o14 & !o15
# i2 & !i4 & !i5 & o14 & !o15
# i2 & i4 & i5 & o14 & !o15;
o15.oe = OE;

!o16 .d !i2
# i2 & !i5 & o15 & o16
# i2 & !i4 & !i5 & o14 & o16
# i2 & i5 & !o16
# i2 & i4 & !o15 & !o16
# i2 & !o14 & !o15 & !o16;
o16.oe = OE;

!o17 .d !i2
# i2 & !i3 & i6 & o17
# i2 & !i3 & o17
# i2 & !i5 & i6 & o17 & !o19
# i2 & i3 & i5 & !o17
# i2 & i3 & !i6 & !o17
# i2 & i3 & !o17 & o19
# i2 & !i6 & !o17 & o19;
o17.oe = OE;

!o18 = i3 & o17
# !i3 & !o17 & o19;

!o19 = !i4 & o15 & o16
# !i4 & o14 & o16;

a 22V10 is in there:
<https://github.com/ezrec/galpal>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From briccus@gmail.com@21:1/5 to Johann Klammer on Wed Aug 18 09:58:17 2021
On Wednesday, 18 August 2021 at 09:45:43 UTC+2, Johann Klammer wrote:

a 22V10 is in there:
<https://github.com/ezrec/galpal>

Thanks for link.Actually I'm dealing with a PAL16R4 a,d GAL16V8, these devices are not included in the examples of the link .I'm also wondering if ispLEVER HDL modules produced after compilation of fusemap are enough to simulate such devices.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From TJ Edmister@21:1/5 to All on Wed Aug 18 16:03:12 2021
On Tue, 17 Aug 2021 17:47:00 -0400, bri...@gmail.com <briccus@gmail.com>
wrote:

Hi all,
I'm translating into Verilog some schematics.I have faced some PLDs (PAL
or GAL),
Some have pure combinatorial logics which is easy to write in Verilog
but other are registered so they need flip flops.I was wondering how to implement the latter.Here an example where you can see four outputs are registered so there is a clock (pin1 of the PAL device) and a output
enable (usually pin11 tied to GND)

/** Inputs **/
Pin 2 = i2;
Pin 3 = i3;
Pin 4 = i4;
Pin 5 = i5;
Pin 6 = i6;
Pin 7 = i7;
Pin 8 = i8;
Pin 9 = i9;
Pin 12 = i12;
Pin 13 = i13;
Pin 14 = i14;
Pin 15 = i15;
Pin 16 = i16;
Pin 17 = i17;
Pin 18 = i18;
Pin 19 = i19;

/** Outputs **/
Pin 12 = o12; /**(Combinatorial, Output feedback output, Active low) **/ Pin 13 = o13; /**(Combinatorial, Output feedback output, Active low) **/ Pin 14 = o14; /**(Registered, Output feedback registered, Active low) **/ Pin 15 = o15; /**(Registered, Output feedback registered, Active low) **/ Pin 16 = o16; /**(Registered, Output feedback registered, Active low) **/ Pin 17 = o17; /**(Registered, Output feedback registered, Active low) **/ Pin 18 = o18; /**(Combinatorial, Output feedback output, Active low) **/ Pin 19 = o19; /**(Combinatorial, Output feedback output, Active low) **/

/** Equations **/

!o12 = o13;
o12.oe = vcc;

!o13 = o17 & o18
# o16 & !o18 & !o19;
o13.oe = vcc;

!o14 .d !i2
# i2 & !i4 & o14
# i2 & i4 & !o14;
o14.oe = OE;

(snipped)

I would suggest declaring your combinatorials as 'wire' or as 'output' in
the module definition, and use 'assign' to specify the equation. Then
declare registered outputs as 'reg' or as 'output reg' in the module definition, and specify these inside an 'always' block.

example defining only o12 (combinatorial) and o14 (registered):

module pal (clk, i2, i4, o12, o13, o14);

input clk;
input i2;
input i4;
output o12;
output o13;
output reg o14;

assign o12 = ~o13;

always @(posedge clk)
begin
o14 <= ~i2 | (i2 & ~i4 & o14) | (i2 & i4 & ~o14);
end

Do you also need to implement the output enables?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From briccus@gmail.com@21:1/5 to TJ Edmister on Wed Aug 18 13:16:53 2021
On Wednesday, 18 August 2021 at 22:03:05 UTC+2, TJ Edmister wrote:

I would suggest declaring your combinatorials as 'wire' or as 'output' in
the module definition, and use 'assign' to specify the equation. Then
declare registered outputs as 'reg' or as 'output reg' in the module definition, and specify these inside an 'always' block.

example defining only o12 (combinatorial) and o14 (registered):

module pal (clk, i2, i4, o12, o13, o14);

input clk;
input i2;
input i4;
output o12;
output o13;
output reg o14;

assign o12 = ~o13;

always @(posedge clk)
begin
o14 <= ~i2 | (i2 & ~i4 & o14) | (i2 & i4 & ~o14);
end

Do you also need to implement the output enables?

I think I need also to implement the output enable.In the PAL16R4 chip (where the equations are from) the output enable is pin 11 which is permanently tied to GROUND.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Johann Klammer@21:1/5 to bri...@gmail.com on Fri Aug 20 10:01:27 2021
On 08/18/2021 06:58 PM, bri...@gmail.com wrote:
On Wednesday, 18 August 2021 at 09:45:43 UTC+2, Johann Klammer wrote:

a 22V10 is in there:
<https://github.com/ezrec/galpal>

Thanks for link.Actually I'm dealing with a PAL16R4 a,d GAL16V8, these devices are not included in the examples of the link .I'm also wondering if ispLEVER HDL modules produced after compilation of fusemap are enough to simulate such devices.

old PLD dataheets usaully contain the fuse numbers and schematics, so a model is easy to write.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From briccus@gmail.com@21:1/5 to Johann Klammer on Sat Sep 11 01:14:45 2021
On Friday, 20 August 2021 at 10:01:41 UTC+2, Johann Klammer wrote:
On 08/18/2021 06:58 PM, bri...@gmail.com wrote:
On Wednesday, 18 August 2021 at 09:45:43 UTC+2, Johann Klammer wrote:

a 22V10 is in there:
<https://github.com/ezrec/galpal>

Thanks for link.Actually I'm dealing with a PAL16R4 a,d GAL16V8, these devices are not included in the examples of the link .I'm also wondering if ispLEVER HDL modules produced after compilation of fusemap are enough to simulate such devices.

old PLD dataheets usaully contain the fuse numbers and schematics, so a model is easy to write.

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing the
extracted equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Johann Klammer@21:1/5 to bri...@gmail.com on Sat Sep 11 21:44:39 2021
On 09/11/2021 10:14 AM, bri...@gmail.com wrote:

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing the
extracted equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

At least the 16R4 one looks ok. I do remember that some of those old softwares add flawed
inversions to the product terms. you may need some external inverters.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Rob Doyle@21:1/5 to bri...@gmail.com on Sat Sep 11 12:54:20 2021
The PAL equations that you showed include tristates on the registered
outputs. The verilog code did not include tristates on the registered
outputs.

I can't tell if the tristates are actually used.

Rob.

On 9/11/2021 1:14 AM, bri...@gmail.com wrote:
On Friday, 20 August 2021 at 10:01:41 UTC+2, Johann Klammer wrote:
On 08/18/2021 06:58 PM, bri...@gmail.com wrote:
On Wednesday, 18 August 2021 at 09:45:43 UTC+2, Johann Klammer
wrote:

a 22V10 is in there: <https://github.com/ezrec/galpal>

Thanks for link.Actually I'm dealing with a PAL16R4 a,d GAL16V8,
these devices are not included in the examples of the link .I'm
also wondering if ispLEVER HDL modules produced after
compilation of fusemap are enough to simulate such devices.

old PLD dataheets usaully contain the fuse numbers and schematics,
so a model is easy to write.

I tried to implement a fully combinatorial PAL and a partially
registered one but they don't work on hardware.I can't figure out
what is wrong, I asked a couple of my friend engineers and they told
me they are correct.Here's the archive containing the extracted
equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From briccus@gmail.com@21:1/5 to Johann Klammer on Sun Sep 12 00:46:39 2021
On Saturday, 11 September 2021 at 21:44:55 UTC+2, Johann Klammer wrote:
On 09/11/2021 10:14 AM, bri...@gmail.com wrote:

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing
the extracted equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

At least the 16R4 one looks ok. I do remember that some of those old softwares add flawed
inversions to the product terms. you may need some external inverters.

Thanks for all your reply.I got the combinatorial PAL16L8 design working, the trick was to use the 'wire' variable since there is feedback of one output (pin 19).i aso applied some delay to outputs.This is the working code tested onto a small CPLD :

default_nettype none
`timescale 1 ns / 100 ps

module PAL16L8_U8(
input i1, i2, i3, i5, i6, i7, i8, i9, i11,
output o12, o13, o14, o15, o16, o17, o18, o19);

wire R19;

assign #7 o12 = ~(i3 & i5 & i6 & ~i7 & i9);

assign #7 o13 = ~(i3 & i5 & ~i6 & ~i7 & i8 & i9);

assign #7 o14 = ~(i3 & ~i5 & i6 & ~i7 & i9);

assign #7 o15 = ~(i3 & ~i5 & ~i6 & ~i7 & i9);

assign #7 o16 = ~((~R19) |
(i3 & R19 & ~i5 & i6 & ~i7 & i9) |
(i3 & R19 & i5 & i6 & ~i7 & i8 & i9));

assign #7 o17 = ~((R19 & ~i5 & ~i8) |
(i3 & R19 & ~i5 & i6 & ~i7 & i8 & i9) |
(i3 & R19 & ~i5 & ~i6 & i7 & i8 & i9));

assign #7 o18 = ~((i3 & R19 & ~i5 & ~i6 & i9) |
(i3 & R19 & i5 & ~i6 & ~i7 & i8 & i9) |
(i3 & R19 & ~i5 & i6 & ~i7 & i8 & i9));

assign #7 R19 = ~(i3 & ~i5 & ~i6 & ~i7 & i8 & i9 & i11);

assign #7 o19 = R19;
endmodule

The registered design is still noy working although also here I modified it using 'wire' and 'reg' variables.Here is code :

module pal16r4_u14
(input wire clk, i2, i3, i4, i5, i6, i7, i8, i9,
output wire o12, o13, o18, o19,
output reg reg_o14, reg_o15, reg_o16, reg_o17);

assign o12 = ~R13;

wire R13;

assign R13 = ~((reg_o17 & R18) |
(o16 & ~R18 & ~R19));

assign o13 = R13;

wire o14;

always @(posedge clk)
begin
reg_o14 <= o14;
end

assign o14 = ~((~i2)
| (i2 & ~i4 & reg_o14)
| (i2 & i4 & ~reg_o14));

wire o15;

always @(posedge clk)
begin
reg_o15 <= o15;
end

assign o15 = ~((~i2)
| (i2 & ~i4 & ~i5 & ~reg_o14 & reg_o15)
| (i2 & ~i4 & i5 & reg_o14 & reg_o15)
| (i2 & i4 & ~i5 & reg_o14 & reg_o15)
| (i2 & i4 & ~reg_o14 & ~reg_o15)
| (i2 & i5 & ~reg_o14 & ~reg_o15)
| (i2 & ~i4 & ~i5 & reg_o14 & ~reg_o15)
| (i2 & i4 & i5 & reg_o14 & ~reg_o15));

wire o16;

always @(posedge clk)
begin
reg_o16 <= o16;
end

assign o16 = ~((~i2)
| (i2 & ~i5 & reg_o15 & reg_o16)
| (i2 & ~i4 & ~i5 & reg_o14 & reg_o16)
| (i2 & i5 & ~reg_o16)
| (i2 & i4 & ~reg_o15 & ~reg_o16)
| (i2 & ~reg_o14 & ~reg_o15 & ~reg_o16));

wire o17;

always @(posedge clk)
begin
reg_o17 <= o17;
end

assign o17 = ~((~i2)
| (i2 & ~i3 & i6 & reg_o17)
| (i2 & ~i3 & reg_o17)
| (i2 & ~i5 & i6 & reg_o17 & ~R19)
| (i2 & i3 & i5 & ~reg_o17)
| (i2 & i3 & ~i6 & ~reg_o17)
| (i2 & i3 & ~reg_o17 & R19)
| (i2 & ~i6 & ~reg_o17 & R19));

wire R18;

assign R18 = ~((i3 & reg_o17) |
(~i3 & ~reg_o17 & R19));

assign o18 = R18;

wire R19;

assign R19 = ~((~i4 & reg_o15 & reg_o16)
| (~i4 & reg_o14 & reg_o16));

assign o19 = R19;

endmodule

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From briccus@gmail.com@21:1/5 to Johann Klammer on Sun Sep 12 10:00:30 2021
On Sunday, 12 September 2021 at 18:28:35 UTC+2, Johann Klammer wrote:
On 09/12/2021 09:46 AM, bri...@gmail.com wrote:
On Saturday, 11 September 2021 at 21:44:55 UTC+2, Johann Klammer wrote:
On 09/11/2021 10:14 AM, bri...@gmail.com wrote:

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing
the extracted equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

At least the 16R4 one looks ok. I do remember that some of those old softwares add flawed
inversions to the product terms. you may need some external inverters.

Thanks for all your reply.I got the combinatorial PAL16L8 design working, the trick was to use the 'wire' variable since there is feedback of one output (pin 19).i aso applied some delay to outputs.This is the working code tested onto a small CPLD :

[...]

I think you've missed an o16 in the PAL16R4:
wire R13;

assign R13 = ~((reg_o17 & R18) |
(o16 & ~R18 & ~R19));

Yes, sorry, it should be :

wire R13;

assign R13 = ~((reg_o17 & R18) |
(reg_o16 & ~R18 & ~R19));

Anyway, it doesn't work the same.I've been told that the feedback output comes in inverted and non inverted form, a fiend of mine did this sheet from the PAL16R4 logics diagram but i can't understand it :

https://i.postimg.cc/15VSHhp9/3-Ca-nfo-C-jpg-medium.jpg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Johann Klammer@21:1/5 to bri...@gmail.com on Sun Sep 12 18:28:11 2021
On 09/12/2021 09:46 AM, bri...@gmail.com wrote:
On Saturday, 11 September 2021 at 21:44:55 UTC+2, Johann Klammer wrote:
On 09/11/2021 10:14 AM, bri...@gmail.com wrote:

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing
the extracted equations from the fusemaps and my Verilog implementations :

https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

At least the 16R4 one looks ok. I do remember that some of those old softwares add flawed
inversions to the product terms. you may need some external inverters.

Thanks for all your reply.I got the combinatorial PAL16L8 design working, the trick was to use the 'wire' variable since there is feedback of one output (pin 19).i aso applied some delay to outputs.This is the working code tested onto a small CPLD :

[...]

I think you've missed an o16 in the PAL16R4:

wire R13;

assign R13 = ~((reg_o17 & R18) |
(o16 & ~R18 & ~R19));

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Johann Klammer@21:1/5 to bri...@gmail.com on Mon Sep 13 13:20:05 2021
On 09/12/2021 07:00 PM, bri...@gmail.com wrote:
On Sunday, 12 September 2021 at 18:28:35 UTC+2, Johann Klammer wrote:
On 09/12/2021 09:46 AM, bri...@gmail.com wrote:
On Saturday, 11 September 2021 at 21:44:55 UTC+2, Johann Klammer wrote: >>>> On 09/11/2021 10:14 AM, bri...@gmail.com wrote:

I tried to implement a fully combinatorial PAL and a partially registered one but they don't work on hardware.I can't figure out what is wrong, I asked a couple of my friend engineers and they told me they are correct.Here's the archive containing
the extracted equations from the fusemaps and my Verilog implementations : >>>>>
https://www.mediafire.com/file/nxiuuart6rdn1hw/PLD_Verilog.zip/file

I hope for help from someone more skilled than me (and my friends...).Thanks in advance.

At least the 16R4 one looks ok. I do remember that some of those old softwares add flawed
inversions to the product terms. you may need some external inverters.

Thanks for all your reply.I got the combinatorial PAL16L8 design working, the trick was to use the 'wire' variable since there is feedback of one output (pin 19).i aso applied some delay to outputs.This is the working code tested onto a small CPLD :

[...]

I think you've missed an o16 in the PAL16R4:
wire R13;

assign R13 = ~((reg_o17 & R18) |
(o16 & ~R18 & ~R19));

Yes, sorry, it should be :

wire R13;

assign R13 = ~((reg_o17 & R18) |
(reg_o16 & ~R18 & ~R19));

Anyway, it doesn't work the same.I've been told that the feedback output comes in inverted and non inverted form, a fiend of mine did this sheet from the PAL16R4 logics diagram but i can't understand it :

https://i.postimg.cc/15VSHhp9/3-Ca-nfo-C-jpg-medium.jpg

What (I think) he means is that the fuse number for the noninverted node is one less than for the inverted node.
this is true if you go by the external visible values, but there's that inverter in the tristate buffer.
so the external visible value is o12 while internally it's !o12.
This is the same with the D-FF which feedback an inverted value aswell.

.->INVBUF->PIN
so while technically it's more correct to have SOP->DFF->INV
FB<-'
it's fine to write SOP->INV->DFF->BUF->PIN
FB<-'
It should be the same wrt exterally observable behaviour.
(this is not true for a 22V10).

what you can not do is read in an external value from a registered cell.

It should not matter anyway if you use software to extract the equations
or wrote them up yourself(if the software works...)

PS: do you have testbed for the thing?

your designs compile without warning in iverilog
but I won't attemt to reconstruct a testbench just to run them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)