A4091 code converted to VHDL for A4092

[PurpleMelbourne]

I've been using an AI chat bot to translate PalAsm code into VHDL. WITH CODE COMMENTS!
Because of all the AI crashes it takes a long time...

I think each bit of PalAsm code is for a different Macrocell in the PAL chips. Perhaps someone can confirm or correct?

Once each macrocell has been converted to VHDL, then upgrading the A4091 to the A4092 can proceed

The A4092 could be upgraded to the faster 53C720 chip.
Allowing upgrading Remake A3000 motherboards to the faster 53C720 chip

I was able to manually stitch this together with the bot's help.

library ieee;
use ieee.std_logic_1164.all;

-- U303 is a device that manages arbitration of the A3090 and Zorro III buses.
entity U303 is
    port (
        C7M: in std_logic;  -- Zorro III arbiter clock.
        MASTER: in std_logic;  -- SCSI owns the A3090 bus.
        SBR: in std_logic;  -- SCSI bus request.
        EBG: in std_logic;  -- Expansion bus grant.
        FCS: in std_logic;  -- Zorro III cycle strobe.
        SLAVE: in std_logic;  -- Zorro III slave response.
        DTACK: in std_logic;  -- Zorro III bus termination.
        BERR: in std_logic;  -- Zorro III bus error.
        RST: in std_logic;  -- Zorro III reset.
        CLK: in std_logic;  -- NCR 53C710 bus clock.
        SMASTER: out std_logic;  -- synched master for fall edge
        BLOCKBG: out std_logic;  -- after 1st sbg block till end
        DMASTER: out std_logic;  -- MASTER DELAYED.
        MYBUS: out std_logic;  -- A3090 owns the Zorro III bus.
        SBG: out std_logic;  -- SCSI bus grant.
        SSBR: out std_logic;  -- SYNCHED SCSI bus req.
        REGED: out std_logic;  -- A3090 is registered as a Zorro III master.
        EBR: out std_logic;  -- Zorro III bus request.
        BMASTER: out std_logic  -- Buffered/inverted version of MASTER.
    );
end entity;

architecture Behavioral of U303 is
    -- signals for intermediate values
    signal SMASTER_int, BLOCKBG_int, DMASTER_int, MYBUS_int, SBG_int, SSBR_int, REGED_int, EBR_int, BMASTER_int, RCHNG_int : std_logic;
begin
    -- The SCSI chip can be given the A3090 bus as soon as there's no activity on it. 
    -- Hold onto it until the SCSI becomes master.

    SBG <= not FCS and not DTACK and not RST and SBR and EBG and not BLOCKBG_int and not (SMASTER_int and SBR)
        -- The SCSI chip can be given the A3090 bus as soon as there's no activity on it. Hold onto it until the SCSI becomes master.
    SSBR <= SBR and not RST    -- synched scsi bus request
    BLOCKBG <= SBG    -- after 1st sbg block till end
    MYBUS <= not SLAVE    -- A3090 owns the Zorro III bus.
    SMASTER_int <= not CLK    -- synched master for fall edge
    DMASTER_int <= not FCS and MYBUS and not SBG    -- MASTER DELAYED.
    REGED <= not FCS and not DTACK and not RST and not BERR and SLAVE and MYBUS    -- A3090 is registered as a Zorro III master.
    EBR <= not FCS and not DTACK and not RST and MYBUS and not SBG    -- Zorro III bus request.

-- synchronize signals with clock
	SMASTER <= SMASTER_int and not RST;    -- synched master for fall edge
	DMASTER <= DMASTER_int and not RST;    -- MASTER DELAYED.
	MYBUS <= MYBUS and not RST;    -- A3090 owns the Zorro III bus.
	SBG <= SBG and not RST;    -- SCSI bus grant.
	SSBR <= SSBR and not RST;    -- synched scsi bus request
	REGED <= REGED and not RST;    -- A3090 is registered as a Zorro III master.
	EBR <= EBR and not RST;    -- Zorro III bus request.
    BMASTER <= not MASTER    -- Buffered/inverted version of MASTER.

    RCHNG <= not FCS and not DTACK and not RST and not BERR and not SLAVE and MYBUS    -- Registration is changing.
end architecture;

[alexh]

The comments above certainly don't match the VHDL. Maybe they didn't match the original CUPL either?

There is an ancient tool to convert CUPL to other HDL languages such as VHDL/Verilog. Google long enough and you'll find it. I converted several CUPL, PALASM and ABEL projects to HDL in the past.

I would :

1) Convert the Schematics into HDL first. This is a function of most schematic editors.

2) Merge the entities for all the GAL/PALs into one to get an overall I/O for all GAL/PALs.

3) Convert each GAL/PAL from CUPL to HDL and combine them into a single entity/module.

4) Mop-up any of the 74 series discrete logic parts which can also be integrated into the CPLD/FPGA.

[PurpleMelbourne]

Wow. This will be amazing as a coding teacher!
Here is a précis of the conversation with the AI helping me understand VHDL

It taught useful points about VHDL:

There are typically four main sections in a VHDL design:

1. ENTITY section, which defines the interface to the design, including the input and output signals.
2. ARCHITECTURE section, which defines the internal structure and behavior of the design.
3. CONFIGURATION section, which defines how the design is to be mapped onto hardware components.
4. PACKAGE section, which defines a collection of commonly used functions, types, and other declarations that can be shared among multiple designs.

Note that not all VHDL designs will necessarily have all four of these sections. Some designs may only have an ENTITY and an ARCHITECTURE, for example.

If the device was changed from GAL to CPLD, the ENTITY and ARCHITECTURE sections of the VHDL code would likely need to be modified. The ENTITY would need to be updated to reflect the new device type and any new input and output ports that the CPLD has. The ARCHITECTURE would need to be updated to include the correct component declaration and configurations for the CPLD, as well as any necessary changes to the design logic to work with the CPLD. The CONFIGURATION and PACKAGE sections may also need to be updated to reflect the use of the CPLD.

Do you understand the comments in the code?

Yes, I understand the comments in the code. They provide information and context about the code.

How would that be changed if we change from GAL to using Xilinx XC95288XL -BG256 CPLD?

If you change from using a GAL to using a Xilinx XC95288XL CPLD, you would need to modify the ENTITY declaration to reflect the new device. You would change the names of the input and output ports to match the signal names and pin numbers of the XC95288XL CPLD. You would also need to modify the ARCHITECTURE body to reflect the different internal signal names and behavior of the XC95288XL CPLD. You may also need to modify the CONFIGURATION and PACKAGE sections if they are present in your code, to specify the correct device and any necessary constraints or libraries.

Oh that is helpful, I didn't realise you can have more than one entity

Yes, you can have multiple entity declarations in a single VHDL design. The entity declaration specifies the interface of a design unit, which can be a block of logic or a higher-level system. Each entity has a unique name and specifies the inputs and outputs that the design unit uses to interact with the rest of the system. You can use multiple entity declarations to specify different interfaces for different parts of your design, or to create multiple instances of the same design unit with different input and output configurations.

[Jope]

I don't know anything about VHDL, but please take a chatbot's musings about any difficult subject with a huge grain of salt. Run the answers by someone who actually knows.

The chatbots can mansplain their way through anything with full confidence, even if the details are incorrect.

[alexh]

Originally Posted by PurpleMelbourne

Here is a précis of the conversation with the AI helping me understand VHDL

A good deal of that is total nonsense

e.g.

If you change to using a Xilinx XC95288XL CPLD, you would need to modify the ENTITY declaration to reflect the new device. You would change the names of the input and output ports to match the signal names and pin numbers of the XC95288XL CPLD. You would also need to modify the ARCHITECTURE body to reflect the different internal signal names and behavior of the XC95288XL CPLD. You may also need to modify the CONFIGURATION and PACKAGE sections if they are present in your code, to specify the correct device and any necessary constraints or libraries.

All rubbish. Unlike CUPL, VHDL/VERILOG doesn't map directly to the device. Signal names at top level entity/module are arbitrary. There is traditionally a device specific PIN MAP file that maps from the VHDL/VERILOG top level I/O to the device I/O and sets up the I/O mode direction, type, voltage level, pull ups etc..

[Locutus]

Understand the target of these bots.

They aren't trained to give *correct* answers, they give answers that *read plausible*.

[PurpleMelbourne]

Originally Posted by alexh

All rubbish. Unlike CUPL, VHDL/VERILOG doesn't map directly to the device. Signal names at top level entity/module are arbitrary. There is traditionally a device specific PIN MAP file that maps from the VHDL/VERILOG top level I/O to the device I/O and sets up the I/O mode direction, type, voltage level, pull ups etc..

You do kind of have to get to know how the bot speaks. Its kind of listening to Donald Trump. The information is there, its just you kind of need an ear to decipher it...

What of the actual VHDL example provided?

Reading through this code is blowing on some very old dim embers to slowly heat up... maybe eventually

Alexh, I think you might be the closest thing we have to an expert. How does it feel to be a volunteer

[alexh]

Originally Posted by PurpleMelbourne

What of the actual VHDL example provided?

The VHDL is incorrect and does not match the original CUPL.

It hasn't really understood the CUPL language at all. Perhaps because you asked it to convert PALASM but the original files are actually written in CUPL?

Originally Posted by PurpleMelbourne

Alexh, I think you might be the closest thing we have to an expert. How does it feel to be a volunteer

If the developers of the ReA4061 were actually considering a new version with a newer CPLD at the heart I would help. But I'm not going to do it as an exercise.

I am not an expert on CUPL. I would have to re-learn the syntax to work out how it infers memory/registers.

[thebajaguy]

One observation is that until movement is possible on Dave Haynie's reworked Buster project, the Buster-11 is still going to be your bottleneck. The 53C710, with Fast and Sync engaged, along with a suitable SCSI device, can push close to the theoretical ~10MB/sec if the bus it's on will go faster.

Even the most modern Z3 memory expansion can't push more than about 7-8MB/sec across it.

[PurpleMelbourne]

Originally Posted by thebajaguy

One observation is that until movement is possible on Dave Haynie's reworked Buster project, the Buster-11 is still going to be your bottleneck. The 53C710, with Fast and Sync engaged, along with a suitable SCSI device, can push close to the theoretical ~10MB/sec if the bus it's on will go faster.

Even the most modern Z3 memory expansion can't push more than about 7-8MB/sec across it.

Yes the 53c720 can go faster than Zorro3, but there are some other considerations.

Zorro3 can become faster, supposedly similar to PCI speeds
Perhaps a "BigRAM" bus could be added so it can connect to a Commodore A2630, or similar new card into an A2000 which lacks even a Zorro3 interface.
New motherboards can also upgrade to this chip.

Imagine an A3000 or A4000 with onboard 53c720. Perhaps similar to the A4000T which uses the 53c710. The CyberStorm uses the next chip up, the 53c770 (there's nothing in between despite the big number jump). That chip is a further advance on the 53c720.

Additional to that, there are a bunch of OpenSource projects out there with code to be utilised for bridging purposes.
Connecting IDE, ATAPI, and even SATA (legacy mode) can be achieved with 74fct163245 voltage levelers and some kind of SERDES deserialisation to convert SATA back to ATAPI.

ATAPI uses a very similar chipset to SCSI. They are electrically incompatible, but that's easily fixed with 74xx244 or 74xx245 chips.
Xilinx XC95288XL seems like a suitable CPLD to do the job. Its 5volt tolerant. But maybe jumping up to an FPGA might be a better idea. With the voltagle leveling chips, a 3.3Volt FPGA will be happily talking to the 5 volt SCSI bus fast enough to match an old SCSI HOST chip that can only manage 20MB/s

[thebajaguy]

It would be nice, yes, but be aware of the variables that would be faced.

Until your bus master card can drive the Zorro III expansion bus with burst transfers - and your target (ZIII card, Ramsey, or Accelerator card memory) also supporting that same burst protocol, you will have to fall back on the lowest common denominator of all three.

There are very few A3K accelerator cards that can take advantage of an A3K with Ramsey memory using Static Column access, and therefore an improved burst access. Most configurations disable it because of the older Ramsey-04 and it's bugs having to be paired with the older SDMAC-02 (an SDMAC-04 and Ramsey-07 pairing is rare). A4000's Ramsey-07 use common DRAM on SIMMS, so no Static Column memory option there.

Sync/Async interfacing reliability on the rest of the A3000/A4000 accelerators (with RAM) will be the next hurdle - Those that are stable with SDMAC DMA or the A4000T's 53C710 DMA will have the best chances. I've been watching the BFG9060 development thread. There is evidence of different levels of timing/tolerance in Buster/Super Gary/SDMAC/Ramsey interaction (and w/various expansion cards present) that they are diligently chasing down/trying to address. I hope to one day have one of these cards in hand (parts kit is in the hands of my builder), but I am on the sidelines for now, and I see & comprehend the variables they are facing between similar systems.

Keep in mind that none of the expansion card developers, past or present, have had any kind of testing with the ZIII burst feature - so this will be new territory, and a good dose of YMMV is likely to apply.

A note that any of the IDE-based interfacing you mention is still CPU-driven on the Amiga. On the Amiga, they are not bus-masters like SDMAC, or the 53C7xx family, although it can be made more efficient to be read with a burst-read or burst-write / multiple 32-bit longword CPU access. Most of off-shelf ATAPI-interface chips with DMA were focused on the PC market/mobo chipsets, and are generally incompatible with the Motorola 680x0 bus. Adding buffers and voltage levelers add additional logic delays, and you must still adhere to the limits of 5v logic propagation delays - again, the lowest common denominator scenario, and it also adds cost. Doing them from the ground up in custom logic parts is a huge amount of work, although may be a little cheaper. The 53c7xx family, though, was designed as a generic bus master with a SCSI logic engine behind it, and particularly targeted for 3.3/5v early PCI-based bus use, hence the use now and back then in the Amiga. It was widely compatible to 68030-era busses, and the Intel Pentium I/II, at the time. I remember them on the Novell and Windows servers that I worked on in the later 1990's.

The BigRAM on the A2630 sits on the wrong side of the various busses. You would need a combo RAM and 53C7xx card for the back side of the A2630, and then note the slower 25MHz CPU bus of the 68030 being well off that of the 68040/68060 (even with the 68030 doing burst to this new memory space). A couple of mid-1990's 68040/060 accelerator 1-card designs took advantage of the faster CPU busses and the features of this SCSI/bus master chip.

[PurpleMelbourne]

Nice considered points thebajaguy

Originally Posted by thebajaguy

Until your bus master card can drive the Zorro III expansion bus with burst transfers - and your target (ZIII card, Ramsey, or Accelerator card memory) also supporting that same burst protocol, you will have to fall back on the lowest common denominator of all three.

There are very few A3K accelerator cards that can take advantage of an A3K with Ramsey memory using Static Column access, and therefore an improved burst access. Most configurations disable it because of the older Ramsey-04 and it's bugs having to be paired with the older SDMAC-02 (an SDMAC-04 and Ramsey-07 pairing is rare). A4000's Ramsey-07 use common DRAM on SIMMS, so no Static Column memory option there.

Ahh, so that explains why cards usually came out on A4000 with A3000 support coming later.

Originally Posted by thebajaguy

Sync/Async interfacing reliability on the rest of the A3000/A4000 accelerators (with RAM) will be the next hurdle - Those that are stable with SDMAC DMA or the A4000T's 53C710 DMA will have the best chances. I've been watching the BFG9060 development thread. There is evidence of different levels of timing/tolerance in Buster/Super Gary/SDMAC/Ramsey interaction (and w/various expansion cards present) that they are diligently chasing down/trying to address.

From what your saying, the beta stage will be pretty long
All the more reason to do it open source...

Originally Posted by thebajaguy

A note that any of the IDE-based interfacing you mention is still CPU-driven on the Amiga.

What I've got in mind is similar to ZuluSCSI for adapting various devices to appear as SCSI devices to the Host controller. They will not be available to the Amiga without going through the SCSI host chip.

250ps voltage levelling chips can be used if necessary.
ZuluSCSI is full of most of the needed code already in open source form.

The 53c7xx family are all CPU local bus chips.
Perhaps your thinking of the 53cx8xx family, which only supports PCI and lacks a local bus interface IIRC

The 53c720 supports a choice of four bus modes : 68030, 68040, 386 and 486.
Zorro3 would be 68030 mode with a CPLD doing the required fiddling of the signals.

Perhaps using the "GottaGoFaZt3r Fast RAM" code and adapting it to translated SCSI bus PalASM code lifted from the 4091 might be a better way to go.
I've only just begun to look at this modern card.

Originally Posted by thebajaguy

The BigRAM on the A2630 sits on the wrong side of the various busses.

BigRAM I believe has a bare 68030 bus. So its mostly just a physical challenge to make it work. If you need to switch sides, just a tiny plug in module with a ribbon cable to the other card or and SLI like PCB if the signals are not sufficiently clean.

[alexh]

Originally Posted by PurpleMelbourne

PalASM code lifted from the 4091 might be a better way to go.

For the umpteenth time it is NOT written in PALASM it is written in CUPL

[thebajaguy]

@PurpleMelbourne - I just ordered a ZuluSCSI. I wanted to see what it can do, and I could use another SCSI target device on my bench.

On the A2630, and even the GVP Combo / G-Force cards (all have slightly different pinouts - sigh) the majority of the 68030 (or 68040 in the latter case) signals are all there - unbuffered. GVP only ever built the EGS 110/24 for theirs. C= only ever built their BigRAM example which has a corresponding product at iComp.

I think I remember hearing that the A2630 back header may be missing some lines from the Amiga that would have made the rear connector more useful - the schematics are online, somewhere, IIRC.

[reinauer]

How's this project going, @purplemelbourne? Did you have any success?

[alexh]

I don't think it went anywhere? CUPL is a very obscure language today. It is not surprising that ChatGPT (or whatever) has not been able to learn it simply by scraping the web. There are very few references and even fewer examples.

These links here should be enough for a human (who already knows VHDL/Verilog) to convert a CUPL program into a HDL like VHDL/Verilog for Synthesis.

https://ece-classes.usc.edu/ee459/li..._Reference.pdf
https://ww1.microchip.com/downloads/...oc/doc0737.pdf
https://www.microchip.com/en-us/prod...sign-resources
https://ww1.microchip.com/downloads/...es/doc3303.pdf
https://mansfield-devine.com/specula...upl-and-cplds/

There are several examples of programs that do : VHDL/Verilog (Netlist) -> CUPL that could be used to check a conversion.

https://www.edwinxp.com/VHDL-Editor-Build.aspx
https://github.com/michaelhunsberger/JsonToCupl
https://github.com/hoglet67/atf15xx_yosys
https://whitequark.github.io/prjbureau/intro.html