Verilog to WinCUPL generator\workflow

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
plasmo
Posts: 1273
Joined: 21 Dec 2018
Location: Albuquerque NM USA

Re: Verilog to WinCUPL generator\workflow

Post by plasmo »

Windfall wrote:
Schematic entry is not lower level design. Your primitives in schematic entry are just HDL coded modules, under the hood. So, very much like using HDL, schematic entry will not dictate how the compiler and optimizer are eventually going to implement your logic. Schematic design is mainly available to allow those who don't (yet) know HDL to make simple designs, or to allow porting an existing knitwork of standard logic chips without having to rethink it in HDL. If anything, schematic entry is a higher level way to design (and a rather bad choice for complex or growing designs).
My reason for designing in schematic is because it is closer to the actual logic implementation (which you appears to disagree) that I can pack more functions with schematic designs than HDL designs. Now it is possible I’m not as good with HDL (10+ years of retirement does that) or Quartus is not good with HDL synthesis, or both, but in Quartus CPLD designs in verilog/VHDL seems not able to squeeze in as much functions as schematics. I’m sure a competent HDL designer with good synthesis tool can come close to the design density of schematic, but I’m not that competent.

With FPGA I absolutely will design in verilog—no reason to do it in schematics.
Bill
User avatar
Windfall
Posts: 229
Joined: 27 Nov 2011
Location: Amsterdam, Netherlands
Contact:

Re: Verilog to WinCUPL generator\workflow

Post by Windfall »

plasmo wrote:
Windfall wrote:
Schematic entry is not lower level design. Your primitives in schematic entry are just HDL coded modules, under the hood.
My reason for designing in schematic is because it is closer to the actual logic implementation (which you appears to disagree) that I can pack more functions with schematic designs than HDL designs. Now it is possible I’m not as good with HDL (10+ years of retirement does that) or Quartus is not good with HDL synthesis, or both, but in Quartus CPLD designs in verilog/VHDL seems not able to squeeze in as much functions as schematics. I’m sure a competent HDL designer with good synthesis tool can come close to the design density of schematic
It's certainly possible that different (default) build settings are used here and there, leading to differences in optimization (effort) or fitting. But it's all HDL intermediately.

When I started designing things in '99 (targeting CPLDs) I used AHDL. In AHDL you were actually describing your logic at a lower level (almost gate level, really). Compilation was also a whole lot quicker ... I think Quartus dropped support for AHDL a long time ago though. EDIT : actually it's still there.
plasmo
Posts: 1273
Joined: 21 Dec 2018
Location: Albuquerque NM USA

Re: Verilog to WinCUPL generator\workflow

Post by plasmo »

AHDL is introduced with MaxPlus tool which is before Quartus. I don't remember the year but it is early 1990's. I still have a hardcopy of AHDL for MaxPlus II that was dated 1995. Lots of Altera's megafunctions are programmed in AHDL so it is likely still in use buried inside various libraries. I recall AHDL was not intuitive for me; even with heavy promotion, I continued to use schematic. Looking at the AHDL manual now I see it is full of schematic to illustrate various AHDL concepts. It reads like Verilog. For me schematic is still the closest equivalent of AND-OR matrix going to a flipflop with feedback and expander--the heart of a macrocell. When I design in schematic I can best visualize how it is implemented in macrocells.
Bill
User avatar
Windfall
Posts: 229
Joined: 27 Nov 2011
Location: Amsterdam, Netherlands
Contact:

Re: Verilog to WinCUPL generator\workflow

Post by Windfall »

plasmo wrote:
For me schematic is still the closest equivalent of AND-OR matrix going to a flipflop with feedback and expander--the heart of a macrocell. When I design in schematic I can best visualize how it is implemented in macrocells.
I always glanced at the actual RTL to get a feel for that (Tools -> Netlist Viewers -> RTL Viewer). It's highly recommended.
mike9repeating
Posts: 3
Joined: 04 May 2023

Re: Verilog to WinCUPL generator\workflow

Post by mike9repeating »

pjdennis wrote:
mike9repeating wrote:
[...] I've come up with a handy way to generate WinCUPL from Verilog using Yosys and a simple utility I wrote called JsonToCupl.
hoglet wrote:
Coincidenally, I also had a go at this a few months ago
Mike, Dave,

What hardware and software are you using to program the ATF15XX devices? I'm using minipro with a TL866 II programmer to program ATF22V10XX's and would like to try more capable PLD chips, such as the ATF1504XX. However I don't believe the TL866 II and minipro support the ATF15XX devices.

-Phil
Hi Phil, I use a ATDH1150USB "USB ISP" Jtag programmer. I wish I had a way around it, it was pricy. For the AFT22V10XX's, I also use a TL866 II Plus.

, Mike.
mike9repeating
Posts: 3
Joined: 04 May 2023

Re: Verilog to WinCUPL generator\workflow

Post by mike9repeating »

hoglet wrote:

Coincidenally, I also had a go at this a few months ago:
https://github.com/hoglet67/atf15xx_yosys
Hi Dave,

Thanks for pointing this out to me. I like your process, its more elegant I think than code generation. Its ironic that you are using WINE, because I couldn't get WinCupl to work properly on windows 10. I use an old XP virtual machine.

Thanks,

Mike.
User avatar
Nemesis
Posts: 8
Joined: 22 Mar 2024

Re: Verilog to WinCUPL generator\workflow

Post by Nemesis »

Bump to say that I've just submitted a pull request for https://github.com/hoglet67/atf15xx_yosys which adds Windows batch scripts to make this toolchain easily accessible for Windows users. I plan to use this over the next few weeks to test out programming ATF1508 devices under Verilog using this toolchain.
hoglet
Posts: 367
Joined: 29 Jun 2014

Re: Verilog to WinCUPL generator\workflow

Post by hoglet »

Nemesis wrote:
Bump to say that I've just submitted a pull request for https://github.com/hoglet67/atf15xx_yosys which adds Windows batch scripts to make this toolchain easily accessible for Windows users. I plan to use this over the next few weeks to test out programming ATF1508 devices under Verilog using this toolchain.
Thanks for this.

I've just merged it (untested as I don't have access to a Windows 10/11 machine)

Please keep up posted on your progress.

Dave
User avatar
Nemesis
Posts: 8
Joined: 22 Mar 2024

Re: Verilog to WinCUPL generator\workflow

Post by Nemesis »

Will do. I forgot to mention in the commit, I didn't preserve the workaround for reversing the port bit order, so the Windows scripts assume Yosys version 0.30+21 or greater.

Have you done any tests with the Synlig plugin for Yosys out of curiosity?
https://github.com/chipsalliance/synlig
Supposedly adds full SystemVerilog support to Yosys. Can you see anything that would prevent that from working with what you've put together? I like the idea of being able to use modules rather than being limited to the pure Verilog syntax.
hoglet
Posts: 367
Joined: 29 Jun 2014

Re: Verilog to WinCUPL generator\workflow

Post by hoglet »

Nemesis wrote:
Have you done any tests with the Synlig plugin for Yosys out of curiosity?
https://github.com/chipsalliance/synlig
Supposedly adds full SystemVerilog support to Yosys. Can you see anything that would prevent that from working with what you've put together?
Sorry, I haven't tried the Synlig plugin. I generally stick to Verilog-2001, because this is the latest version supported by Xilinx ISE (for the Spartan 6 parts).

I don't see any reason why it wouldn't work though.
Nemesis wrote:
I like the idea of being able to use modules rather than being limited to the pure Verilog syntax.
All versions of the Verilog language support parameterized modules.

My understanding was that SystemVerilog adds more data types and interfaces (groups of ports).

What aspect of modules requires SystemVerilog? the interfaces feature?

Dave
User avatar
Nemesis
Posts: 8
Joined: 22 Mar 2024

Re: Verilog to WinCUPL generator\workflow

Post by Nemesis »

You're right, my bad. I've only used SystemVerilog prior to now, I probably have some more incorrect ideas about the differences rattling around.
Jmstein7
Posts: 379
Joined: 30 May 2021

Re: Verilog to WinCUPL generator\workflow

Post by Jmstein7 »

Nemesis wrote:
You're right, my bad. I've only used SystemVerilog prior to now, I probably have some more incorrect ideas about the differences rattling around.
Ditto - I've only used HDL until now, too. This is very different.

Jonathan
User avatar
Nemesis
Posts: 8
Joined: 22 Mar 2024

Re: Verilog to WinCUPL generator\workflow

Post by Nemesis »

Hey hoglet, I've hit some synthesis errors I don't understand with the yosys toolchain, wondering if you could take a look? Here's a stripped down example:

Code: Select all

module Bug
    (
    output reg  signal,
    input wire   CLK
    );

    reg currentState;
    reg signalChangePending;

    always @(posedge CLK) begin
      if (signalChangePending) begin
        signal <= ~signal;
        signalChangePending <= 0;
      end
    end

    always @(negedge CLK) begin
      if (currentState == 1) begin
          signalChangePending <= 1;
          currentState <= 0;
      end
      else begin
          currentState <= 1;
      end
    end

endmodule
// Pin assignment for the experimental Yosys FLoow
//
//PIN: CHIP "Bug" ASSIGNED TO AN PLCC84
//PIN: signal : 74
//PIN: CLK    : 83
When you save this as bug.v and try and build it with your toolchain, it looks like the Yosys part gets a bit confused and fails to produce a valid edif file. If I'm reading the logs right, the core of the problem seems to be that Yosys decides the "always @(negedge CLK)" logic block has no effect and throws it out. This occurs during the "synth" step when running "PROC_CLEAN". This has a flow-on effect with other bits then getting optimized away, and by the end it creates an EDIF file with the "signal" pin represented by a "BUF" cell with Q (output) linked to the port, but nothing linked to A (input), which the fitter then rejects.

If you have the time, do you think you could take a look and see if I'm doing something dumb here, or if there's a bug that needs addressing?

I'm testing this on Windows. Here's the yosys build I'm running: Yosys 0.39+149 (git sha1 b9d3bffda, x86_64-w64-mingw32-g++ 13.2.1 -Os)
Attachments
Bug.log
(28.55 KiB) Downloaded 254 times
hoglet
Posts: 367
Joined: 29 Jun 2014

Re: Verilog to WinCUPL generator\workflow

Post by hoglet »

Nemesis wrote:
If you have the time, do you think you could take a look and see if I'm doing something dumb here, or if there's a bug that needs addressing?
This doesn't look like sensible Verilog to me.

Specifically, you are assigning to signalChangePending in two seperate blocks, which is not legal.

In response, Yosys is giving the following warning:

Code: Select all

Checking module Bug...
Warning: multiple conflicting drivers for Bug.\signalChangePending:
    port Q[0] of cell $procdff$16 ($dff)
    port Q[0] of cell $procdff$18 ($dff)
Found and reported 1 problems.
Are you trying to synthesise a register that is clocked off both edges of the clock?

Such a register doesn't exist in Atmel CPLDs.

Maybe you could step back and give a bit more context...

Dave
User avatar
Nemesis
Posts: 8
Joined: 22 Mar 2024

Re: Verilog to WinCUPL generator\workflow

Post by Nemesis »

hoglet wrote:
This doesn't look like sensible Verilog to me.

Specifically, you are assigning to signalChangePending in two seperate blocks, which is not legal.
Aha! Thanks, that's what I was missing. I didn't realize there was that restriction. Changed the example to this and it builds as expected:

Code: Select all

module Bug
    (
    output reg  signal,
    input wire   CLK
    );

    reg currentState = 0;
    reg signalChangePending = 0;

    always @(posedge CLK) begin
      if (signalChangePending) begin
        signal <= ~signal;
      end
    end

    always @(negedge CLK) begin
      if (signalChangePending) begin
        signalChangePending <= 0;
      end
      else if (currentState == 1) begin
          signalChangePending <= 1;
          currentState <= 0;
      end
      else begin
          currentState <= 1;
      end
    end

endmodule
// Pin assignment for the experimental Yosys FLoow
//
//PIN: CHIP "Bug" ASSIGNED TO AN PLCC84
//PIN: signal : 74
//PIN: CLK    : 83
As for what this was trying to do, well it was a contrived stripped down example of an issue I hit trying to write a real verilog definition of a bus controller for a 68000 system. This is a bit of an unusual system designed to push into the corner-cases of the 68000 behaviour. I'm doing some strange things, one of which is testing the bus retry logic of the 68000. I was trying to honor this section of the 68000 Users Manual related to signal timing:

"5.6 THE RELATIONSHIP OF DTACK, BERR, AND HALT

To properly control termination of a bus cycle for a retry or a bus error condition, DTACK,
BERR, and HALT should be asserted and negated on the rising edge of the processor
clock. This relationship assures that when two signals are asserted simultaneously, the
required setup time (specification #47, Section 9 Electrical Characteristics) for both of
them is met during the same bus state. External circuitry should be designed to
incorporate this precaution. A related specification, #48, can be ignored when DTACK,
BERR, and HALT are asserted and negated on the rising edge of the processor clock."


I had an event I detected that occurs on a falling edge, and I was trying to flag the three control signals DTACK, BERR, or HALT on the next rising clock edge as a result. This resulted in me setting a "signalChangePending" flag for each one, which I was setting from one block, and picking up and clearing from another. Now that I understand that's not legal I can use a different approach.

I've got 25+ years in software development, but when it comes to Verilog, to date my experience is mostly in browsing and unpacking things other people have written. This is the first time I'm trying to build something from scratch, so I'm going to run into a lot of beginner mistakes I'm sure. I'm off reading more now about multiple clock domains and how this stuff all gets synthesized. Happy to accept tutorial/book/reference recommendations! Mostly working my way systematically through the reference at https://www.chipverify.com/tutorials/verilog right now.
Post Reply