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

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.

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

I always glanced at the actual RTL to get a feel for that (Tools -> Netlist Viewers -> RTL Viewer). It's highly recommended.

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.

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.

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

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.

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.

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

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

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:


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)

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:


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

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:


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.