[cctalk] Re: Good C to FPGA/PLA compiler
Paul I endorse your point regarding Lattice's gouging. Support for anything prior to the XO parts now costs a significant premium. Their XO2 parts are the most useful to this community - free tools and 0.5 mm pitch, e.g. 100p & 144p - not dense but usefully large, 3v3 IO and agricultural assembly. The Xilinx free tools no longer have license files, which was how Lattice cut us all off at the pass. The current Vivado ML Standard Edition (tools to normal people) are free up to the XC7Z030 - which is a fairly serious device. I have a PDP-11 and space to spare running in the markedly smaller XC7Z010; 16b / no MMU, most of the 45 instruction set. FPGA are (organically) memory poor - perhaps because the access time is ~3 ns. I should think you would be in with a chance of fitting the 6600 logic, however on a '30 you have 265 x 4 ki by BRAMs = ~1 Mi By, if more is required either a dedicated external memory device or DMA to/fr DRAM would be required. Martin -Original Message- From: Paul Koning [mailto:paulkon...@comcast.net] Sent: 23 September 2023 01:46 To: cctalk@classiccmp.org Cc: Martin Bishop Subject: Re: [cctalk] Good C to FPGA/PLA compiler > On Sep 22, 2023, at 3:59 PM, Martin Bishop via cctalk > wrote: > > 100% disagree, Verilog and SV are bad tools - very easy to do a bad job with > - penknife grade. > > Verilog however is very c like in that it is untyped and prone to all the > consequent tar pits; see above. > > VHDL is a good tool which is typed and like the Algol family of languages > precludes many follies. > The 2008 flavor, which is where the tools are curently, is not as pedantic as > the older standards '97 & '83. I only know VHDL but I had heard that Verilog is C-like, and yes, C offers an unusually large set of tools to shoot yourself in the foot with. So it wouldn't surprise me that Verilog does likewise, which certainly means that it would be the option to avoid. VHDL is very clearly based on Ada, which like Pascal and ALGOL takes data types seriously rather than only as suggestions the way C does. I've built some very large designs with VHDL, but not because I actually wrote that much code -- a lot is generated code produced from wire lists. But I did write all the models of all the 6000 modules, which does add up. Apart from vendor tools for producing bits for particular FPGAs, you can also find VHDL simulators that just simulate a model but don't deliver it to a particular chip. I use GHDL, which is part of the GCC toolset. Yes, a VHDL compiler, interesting. Among other things, it allows you to link bits in other languages, so I can take device models from the DtCyber emulator and attach them to a VHDL-modeled I/O channel. On FPGAs, it's worth checking what the story is for vendor tools. Some devices and vendors try to suck large sums of money out of you for them; Lattice is an example. Even for small devices (like the ispLSI2032 I used years ago) that expense adds up rapidly. I think they have become somewhat more reasonable now, offering free tools for the smaller devices. I know Xilinx does so, and "smaller" covers a surprising amount of capacity these days. I'm pretty sure a PDP-11 model would fit fine in one of those "free tool" devices, though a CDC 6600 probably won't. paul
[cctalk] Re: Good C to FPGA/PLA compiler
> On 09/22/2023 6:26 PM CDT Mike Katz via cctalk wrote: > > > I plan on controlling the gate array with an RP2040 dual core cortex M0 > running at 133 MHz and 8 PIO processors. > Hi Mike, Since you are planning to use a micro anyway, and it doesn't appear you will need a great deal of external logic, you might consider one of the micros that has some programmable logic on board. Cypress PSOC is the prototypical example: https://www.infineon.com/cms/en/product/microcontroller/32-bit-psoc-arm-cortex-microcontroller/ They have a wide variety starting with Cortex M0 and going up, with varying amounts of programmable logic. Their tools are pretty nice, too, with pre-built modules and also allowing you to drop into raw HDL if you need or want to. They have a nice selection of reasonably priced dev boards to get started. Will If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery
[cctalk] Re: Good C to FPGA/PLA compiler
> On Sep 22, 2023, at 3:59 PM, Martin Bishop via cctalk > wrote: > > 100% disagree, Verilog and SV are bad tools - very easy to do a bad job with > - penknife grade. > > Verilog however is very c like in that it is untyped and prone to all the > consequent tar pits; see above. > > VHDL is a good tool which is typed and like the Algol family of languages > precludes many follies. > The 2008 flavor, which is where the tools are curently, is not as pedantic as > the older standards '97 & '83. I only know VHDL but I had heard that Verilog is C-like, and yes, C offers an unusually large set of tools to shoot yourself in the foot with. So it wouldn't surprise me that Verilog does likewise, which certainly means that it would be the option to avoid. VHDL is very clearly based on Ada, which like Pascal and ALGOL takes data types seriously rather than only as suggestions the way C does. I've built some very large designs with VHDL, but not because I actually wrote that much code -- a lot is generated code produced from wire lists. But I did write all the models of all the 6000 modules, which does add up. Apart from vendor tools for producing bits for particular FPGAs, you can also find VHDL simulators that just simulate a model but don't deliver it to a particular chip. I use GHDL, which is part of the GCC toolset. Yes, a VHDL compiler, interesting. Among other things, it allows you to link bits in other languages, so I can take device models from the DtCyber emulator and attach them to a VHDL-modeled I/O channel. On FPGAs, it's worth checking what the story is for vendor tools. Some devices and vendors try to suck large sums of money out of you for them; Lattice is an example. Even for small devices (like the ispLSI2032 I used years ago) that expense adds up rapidly. I think they have become somewhat more reasonable now, offering free tools for the smaller devices. I know Xilinx does so, and "smaller" covers a surprising amount of capacity these days. I'm pretty sure a PDP-11 model would fit fine in one of those "free tool" devices, though a CDC 6600 probably won't. paul
[cctalk] Re: Good C to FPGA/PLA compiler
Martin, Thank you for all of your suggestions. I am a software guy who has dabbled in hardware since I built my first Heathkit in 1972. I have designed simple 6809 single boards in my past professional life but the Omnibus is several orders of magnitude more complicated than a 6809. Just reading the Single Cycle Data Break documentation in the Omnibus spec is enough to give me a headache. I think in C much better than I think in logic gates. I can write parallel C to describe parallel circuits. The last time I programmed any programmable logic it was FPGA's of the 10L8/16V10 variety. Sometimes the data is on the memory bus, sometimes it is on the data bus, depending on whether you are reading or writing to memory, for example. There is no bus multplexing between address and data or data and memory busses. Here is the basic definition of the Omnibus: Memory Address: 15 Signals Memory Data: 12 Signals Memory Direction: 1 Signal Data Bus: 12 Signals I/O Control Signals: 10 Signals DMA Control Signals: 8 Signals Timing Signals: 9 Signals CPU State: 6 Signals Memory Timing: 5 Signals Misc Signals: 18 Signals (Mostly used by the front panel) One of my goals here is to use thru hole parts and sockets so the average person can assemble it. I realize this may be impossible bit I'm trying. I have a good surface mount contract manufacturer close to my home that I have a business relationship will so I can go to full surface mount if I have to but that will increase the cost of the boards. On 9/22/2023 6:53 PM, Martin Bishop via cctalk wrote: Mike An M0 will require an FPGA below it to interact with the OmniBus A BeagleBone, using the PRUs - which are ~microcoded, would be in with more of a chance Industrial grade SoCs / FPGAs should have no difficulty Martin -Original Message- From: Mike Katz via cctalk [mailto:cctalk@classiccmp.org] Sent: 23 September 2023 00:27 To: General Discussion: On-Topic and Off-Topic Posts Cc: Mike Katz Subject: [cctalk] Re: Good C to FPGA/PLA compiler I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range. The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point. In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing. This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote: Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
Mike An M0 will require an FPGA below it to interact with the OmniBus A BeagleBone, using the PRUs - which are ~microcoded, would be in with more of a chance Industrial grade SoCs / FPGAs should have no difficulty Martin -Original Message- From: Mike Katz via cctalk [mailto:cctalk@classiccmp.org] Sent: 23 September 2023 00:27 To: General Discussion: On-Topic and Off-Topic Posts Cc: Mike Katz Subject: [cctalk] Re: Good C to FPGA/PLA compiler I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range. The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point. In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing. This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote: > Stupid question, I know, but someone has to ask it. > > Is there some overwhelming reason that the FPGA and associated logic > couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, > 200 MHz? I can't believe that a PDP8 is all that fast... > > --Chuck > >
[cctalk] Re: Good C to FPGA/PLA compiler
I have no plans to emulate the CPU. This is intended to be a board to help debug programs and possibly some hardware issues. On 9/22/2023 6:06 PM, Martin Bishop via cctalk wrote: Chuck, Your point is wholly valid, although the core will run more at 1 GHz than 200 MHz. The UniBone http://retrocmp.com/projects/unibone is a UniBus board capable of monitoring the unibus and of emulating CPU / rotating rust / memory / ... With the bulk of the logic in c on an Arm Processor. Jay Jaeger has just elaborated the UniBone's essentials. Martin -Original Message- From: Chuck Guzis via cctalk [mailto:cctalk@classiccmp.org] Sent: 22 September 2023 23:53 To: ben via cctalk Cc: Chuck Guzis Subject: [cctalk] Re: Good C to FPGA/PLA compiler Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range. The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point. In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing. This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote: Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
Chuck, Your point is wholly valid, although the core will run more at 1 GHz than 200 MHz. The UniBone http://retrocmp.com/projects/unibone is a UniBus board capable of monitoring the unibus and of emulating CPU / rotating rust / memory / ... With the bulk of the logic in c on an Arm Processor. Jay Jaeger has just elaborated the UniBone's essentials. Martin -Original Message- From: Chuck Guzis via cctalk [mailto:cctalk@classiccmp.org] Sent: 22 September 2023 23:53 To: ben via cctalk Cc: Chuck Guzis Subject: [cctalk] Re: Good C to FPGA/PLA compiler Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
On 9/22/2023 4:45 PM, ben via cctalk wrote: On 2023-09-22 3:16 p.m., Mike Katz via cctalk wrote: Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks. Hexadecimal displays til311, (pulled DIS1417's) can be found on ebay for about $5 not counting shipping. This way you have easy to read hex or octal numbers. As an alternative, perhaps consider basing a design on the PDP-11 QBone/UniBONE boards, with bus interface chips to handle the 5V UNIBUS signalling and a Beagle Bone with it's attached processors (PRU) for the bus interface. That would allow a lot of work to be done in plain old C/C++/Whatever, and the board could serve as a debug board, peripheral emulator, whatever based on whatever software was loaded onto BB. Also, if one would want to do logic in an FPGA, VHDL and Verilog aren't *that* hard to learn if one has a background in hardware. Some resources include: Logic and Computer Design Fundamentals, Mano/Kime, Prentice Hall Digital Design using Digilent FPGA Boards (There are VHDL and Verilog editions) Advanced Digital Design Using Digilent FPGA Boards Even if one is not using Digitlent boards, the examples given for various typical uses cases for things are helpful (counters, state machines, multiplexers, selectors etc. etc.) JRJ
[cctalk] Re: Good C to FPGA/PLA compiler
Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
My plan is to have both a serial port for connection to a PC/Terminal and an I2C output to a multi line display. Thanks for the suggestion. On 9/22/2023 4:45 PM, ben via cctalk wrote: On 2023-09-22 3:16 p.m., Mike Katz via cctalk wrote: Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks. Hexadecimal displays til311, (pulled DIS1417's) can be found on ebay for about $5 not counting shipping. This way you have easy to read hex or octal numbers.
[cctalk] Re: Good C to FPGA/PLA compiler
On 2023-09-22 3:16 p.m., Mike Katz via cctalk wrote: Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks. Hexadecimal displays til311, (pulled DIS1417's) can be found on ebay for about $5 not counting shipping. This way you have easy to read hex or octal numbers.
[cctalk] Re: Good C to FPGA/PLA compiler
Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks.
[cctalk] Re: Good C to FPGA/PLA compiler
On 2023-09-22 12:34 p.m., emanuel stiebler via cctalk wrote: On 2023-09-22 12:04, Mike Katz via cctalk wrote: I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not very good at circuit design. I know there are programs that will compile something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind of large (more than 64 pins) programmable logic device. There are still some 84pin chips out there(Altera & Xilinx). Sometimes they are pulls, or some 5V tolerant xilinx xc95l Can any of you recommend a good C like tool for programmable logic? Stay away from them :) At the end, you will spend as much time learning the differences (as it is not real "C") so invest the time in learning system verilog or VHDL. VHDL is a little more verbose, system verilog lets you shoot in your foot much easier. I hate both. You can't shoot yourself in the foot, because you can never figure where the feet are with all that verbose. If you just like to "debug" the bus, get an FPGA & some level shifters, very easy to do ... I use ADHL. It is vender specific, but I can figure out the logic. FPGA's have too many vender specific features,to go from one brand to the other. Schematic capture, is the other option. One gota with FPGA's, flip flops only have asyncronus clears, not preset.
[cctalk] Re: Good C to FPGA/PLA compiler
Mike
The level you are working at, inspecting busses, is not really where C like
tools are targeted - however ...
I shall infer that an 8/E debug board has the functionality of a bus monitor /
logic analyser front end.
The recent discussion <> covered
a lot of similar ground : worth reviewing.
Also, the debug tools for 11's on http://retrocmp.com/
https://digilent.com/shop/cora-z7-zynq-7000-single-core-for-arm-fpga-soc-development/
provides ~79 IOs on an Arduino footprint ('orrible) - quick cheap suggestion
for a candidate hardware platform.
That means you are using the AMD (Xilinx) toochain:
- Vivado as the HDL IDE : VHDL & Verilog, a flakey simulator, HLS (High Level
Synthesis) [c like] tools and IP generation capabilities.
-- inside Vivado a block diagram editor which with a bit of pro forma IP
generation might build your logic without any HDL
-- also inside the IP library / Vivado logic analyser capabilities (ILAs) for
capturing / displaying bus signals
-- and HLS implements SystemC or somesuch : a toolset for C to parallel
hardware development
- Vitis, which is basically Eclipse, for programming the hard Arm core(s)
If you wish an HDL simulator, download Microchip's FPGA development tools - you
get ModelSim.
This will be quite sufficient for pre-synthesis bebug, if you have to simulate
post synthesis revisit the design fundamentals.
There was discussion further up the chain of voltage translation / clipping.
Another cheap and nasty way of doing it is Zenner diodes - works well on perf
board.
Todays (fairly) Gucci voltage clamp is an N-FET with a suitable gate voltage;
there were "octal" devices using this teknik.
Voltage translation devices remain quite common, but anything more assembly
friendly than SOIC less common.
However,74LVT is both 3v3 powered, possessed of 5V tollerant inputs and (maybe
just still) in DIL packages, e.g. 74LVT244
Another handy family is 74LVC1G (and 2G ...) which also accepts 5V inputs when
running on 3v3 rails, e.g. 74LVC1G17
If you require HiZ, specific thresholds or hysteresis, comparators are your
friend, e.g. TLV3501AIDBV (SOT-23)
Best Wishes
Martin
-Original Message-
From: Mike Katz via cctalk [mailto:cctalk@classiccmp.org]
Sent: 22 September 2023 17:05
To: General Discussion: On-Topic and Off-Topic Posts
Cc: Mike Katz
Subject: [cctalk] Good C to FPGA/PLA compiler
I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not
very good at circuit design. I know there are programs that will compile
something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind of
large (more than 64 pins) programmable logic device.
Can any of you recommend a good C like tool for programmable logic?
Thank you,
Mike
[cctalk] Re: Good C to FPGA/PLA compiler
100% disagree, Verilog and SV are bad tools - very easy to do a bad job with - penknife grade. Verilog however is very c like in that it is untyped and prone to all the consequent tar pits; see above. VHDL is a good tool which is typed and like the Algol family of languages precludes many follies. The 2008 flavor, which is where the tools are curently, is not as pedantic as the older standards '97 & '83. However, any non trivial FPGA design work requires an understanding of FPGA (not SSI/MSI) logic, an HDL and the toolchain(s). Quite a lot of learning / experience. Martin Oh, and Verilog all the way. I just can't with VHDL. 😆 -- Anders Nelson www.andersknelson.com Can any of you recommend a good C like tool for programmable logic? Thank you, Mike
[cctalk] Re: Good C to FPGA/PLA compiler
Oh, and Verilog all the way. I just can't with VHDL. 😆 -- Anders Nelson www.andersknelson.com On Fri, Sep 22, 2023 at 3:24 PM Anders Nelson wrote: > Maybe these can help?: > > > https://www.olimex.com/Products/FPGA/iCE40/iCE40HX1K-EVB/open-source-hardware, > pair with > https://www.olimex.com/Products/FPGA/iCE40/iCE40-DIO/open-source-hardware > > https://www.crowdsupply.com/1bitsquared/icebreaker-fpga > > I've personally used the iCE40 and iCE5LP in my larger designs, > wonderfully capable and affordable devices. > > =] > -- > Anders Nelson > www.andersknelson.com > > > On Fri, Sep 22, 2023 at 3:07 PM Chuck Guzis via cctalk < > cctalk@classiccmp.org> wrote: > >> On 9/22/23 11:34, emanuel stiebler via cctalk wrote: >> >> > There are still some 84pin chips out there(Altera & Xilinx). Sometimes >> > they are pulls, or some 5V tolerant xilinx xc95l >> >> I still have a few 84 pin PLCC XC95108 5V CPLDs Originally, I did a >> tape controller design with one before Xilinx discontinued them. I >> figured that using a discontinued part was not the way forward, so I >> dropped the project. Xilinx did/does have its ISE design suite, which >> is fairly easy to use. >> >> Eventually, it turned out that using a reasonably fast MCU with 5V >> tolerant I/O worked just as well and avoided the "mystery in a chip" of >> a CPLD. >> >> --Chuck >> >>
[cctalk] Re: Good C to FPGA/PLA compiler
Maybe these can help?: https://www.olimex.com/Products/FPGA/iCE40/iCE40HX1K-EVB/open-source-hardware, pair with https://www.olimex.com/Products/FPGA/iCE40/iCE40-DIO/open-source-hardware https://www.crowdsupply.com/1bitsquared/icebreaker-fpga I've personally used the iCE40 and iCE5LP in my larger designs, wonderfully capable and affordable devices. =] -- Anders Nelson www.andersknelson.com On Fri, Sep 22, 2023 at 3:07 PM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > On 9/22/23 11:34, emanuel stiebler via cctalk wrote: > > > There are still some 84pin chips out there(Altera & Xilinx). Sometimes > > they are pulls, or some 5V tolerant xilinx xc95l > > I still have a few 84 pin PLCC XC95108 5V CPLDs Originally, I did a > tape controller design with one before Xilinx discontinued them. I > figured that using a discontinued part was not the way forward, so I > dropped the project. Xilinx did/does have its ISE design suite, which > is fairly easy to use. > > Eventually, it turned out that using a reasonably fast MCU with 5V > tolerant I/O worked just as well and avoided the "mystery in a chip" of > a CPLD. > > --Chuck > >
[cctalk] Re: Good C to FPGA/PLA compiler
On 9/22/23 11:34, emanuel stiebler via cctalk wrote: > There are still some 84pin chips out there(Altera & Xilinx). Sometimes > they are pulls, or some 5V tolerant xilinx xc95l I still have a few 84 pin PLCC XC95108 5V CPLDs Originally, I did a tape controller design with one before Xilinx discontinued them. I figured that using a discontinued part was not the way forward, so I dropped the project. Xilinx did/does have its ISE design suite, which is fairly easy to use. Eventually, it turned out that using a reasonably fast MCU with 5V tolerant I/O worked just as well and avoided the "mystery in a chip" of a CPLD. --Chuck
[cctalk] Re: Good C to FPGA/PLA compiler
On 2023-09-22 12:04, Mike Katz via cctalk wrote: I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not very good at circuit design. I know there are programs that will compile something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind of large (more than 64 pins) programmable logic device. There are still some 84pin chips out there(Altera & Xilinx). Sometimes they are pulls, or some 5V tolerant xilinx xc95l Can any of you recommend a good C like tool for programmable logic? Stay away from them :) At the end, you will spend as much time learning the differences (as it is not real "C") so invest the time in learning system verilog or VHDL. VHDL is a little more verbose, system verilog lets you shoot in your foot much easier. If you just like to "debug" the bus, get an FPGA & some level shifters, very easy to do ...
[cctalk] Re: Good C to FPGA/PLA compiler
> On Sep 22, 2023, at 12:04 PM, Mike Katz via cctalk > wrote: > > I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not > very good at circuit design. I know there are programs that will compile > something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind > of large (more than 64 pins) programmable logic device. > > Can any of you recommend a good C like tool for programmable logic? > > Thank you, > > Mike Spartan 2 FPGAs have (among other things) 3.3 volt output drivers, with a minimum high output spec of 2.4 volts. That's probably good enough to drive 5 volt TTL devices. (FWIW, I've had good luck driving 5V logic from the 3.3 volt I/O of a Raspberry Pico. Not quite the same but similar). They also show 5 volt tolerant inputs, so while the device is powered by 3.3 volt it can accept 5V TTL inputs without complaint. I recently built a device that had a lot of inputs to that Raspberry Pico, which is documented as NOT 5V tolerant. So instead of searching for level shifters I simply used an array of resistive voltage dividers. Worked flawlessly. As for a C like tool, I've heard of something called "System C" for logic design. No idea if it is reality for any FPGA, let alone for the older ones. The difficulty is that C is a sequential system description, which is fine for (single core) computers. But logic such as FPGAs does many things concurrently, and that calls for a different way of describing what you need. I'd suggest learning VHDL; it isn't all that hard. Or Verilog I suppose, which I don't know. Years ago I bought Peter Ashenden's "Designer's guide to VHDL" which is very good. paul
[cctalk] Re: Good C to FPGA/PLA compiler
FPGA's tend to be ALL 3.3 volts or less today. Cmos 22v10's are nice chips to program that is still working at 5 volts. FPGA's also have high learning curve to catch the bugs and gotya's. I got tl866 ii + programer and it works great under windows, with wincupl.
[cctalk] Re: Any leads on Fairlight sampler that needs repair?
You will likely learn a lot by watching this series: https://www.youtube.com/watch?v=xmCrbUk1evc (we're up to Episode 17, be warned!). Or, to dream about hiring a pro: https://www.youtube.com/watch?v=BNdZowgySnE http://ghservices.com/gregh/fairligh/ - Kurt -Original Message- From: Ethan O'Toole Sent: Friday, September 22, 2023 9:42 AM To: Sellam Abraham via cctalk Cc: Sellam Abraham Subject: [cctalk] Re: Any leads on Fairlight sampler that needs repair? That's why I said broken! A boy can dream! - Ethan > They are a fairly high demand item when they come up for sale, and are > very expensive. > > Sellam
[cctalk] Good C to FPGA/PLA compiler
I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not very good at circuit design. I know there are programs that will compile something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind of large (more than 64 pins) programmable logic device. Can any of you recommend a good C like tool for programmable logic? Thank you, Mike
[cctalk] Re: Any leads on Fairlight sampler that needs repair?
That's why I said broken! A boy can dream! - Ethan They are a fairly high demand item when they come up for sale, and are very expensive. Sellam
[cctalk] Re: IBM VM "CMS" tape format
On 9/22/23 01:57, Peter Coghlan via cctalk wrote: > > It looks like a disk FST tweaked for writing to tape to me. Using the FST > layout in LY24-5221-2 referenced by Dennis earlier, I think maybe it might > be interpreted something like below. Apologies if I've mixed anything up > here. Thank you, Peter. If additional samples of CMSN records would help clarify things, I can supply them. The tape itself appears to contain data from a run of SAS Institute's (https://www.sas.com/en_us/home.html) software. I can determine that it was run between the last months of 1984 and the early months of 1985 on a 3083. The client has expressed an enthusiastic interest in the content. --Chuck
[cctalk] Re: Any leads on Fairlight sampler that needs repair?
They are a fairly high demand item when they come up for sale, and are very expensive. Sellam On Fri, Sep 22, 2023, 9:02 AM Ethan O'Toole via cctalk < cctalk@classiccmp.org> wrote: > Anyone have any leads in USA on a Fairlight CMI or similar that needs > repair? S-100 based sampler from the 80s. Would be fun to restore one. > > - Ethan >
[cctalk] Any leads on Fairlight sampler that needs repair?
Anyone have any leads in USA on a Fairlight CMI or similar that needs repair? S-100 based sampler from the 80s. Would be fun to restore one. - Ethan
[cctalk] Re: IBM VM "CMS" tape format
>
> Thanks for the information so far, folks.
>
> Now this boils down to interpreting the final CMS record for each file.
> I'm not clear on how to interpret them, however. For example,
>
>> Block 10, 87 bytes:
>> 00 02 c3 d4 e2 d5 01 76 00 01 c1 f1 01 75 00 00 c6 |.CMSNA1F|
>> 10 00 00 00 00 50 00 08 f8 f4 12 05 12 31 00 00 01 |&..84...|
>> 20 3b 00 00 00 08 00 00 01 75 01 04 84 12 05 12 31 |...d|
>> 30 21 00 00 00 00 e4 e3 c5 40 e2 c1 e2 c6 c9 d3 c5 |.UTE SASFILE|
>> 40 40 00 00 00 00 c3 c8 c5 c3 d2 f1 40 40 d7 e2 c1 | CHECK1 PSA|
>> 50 e2 40 40 40 40 c1 f1 |SA1 |
>
> I can figure some parts of it; for example, the hex 50 at offset 0x14
> apparently is the record length. I'm guessing that the 01 04 84 might
> be a date code in packed BCD.
>
> Guesses welcome !
>
It looks like a disk FST tweaked for writing to tape to me. Using the FST
layout in LY24-5221-2 referenced by Dennis earlier, I think maybe it might
be interpreted something like below. Apologies if I've mixed anything up
here.
?01 76 Dunno
?00 01 Dunno
FSTFMODE c1 f1 (Filemode A1)
FSTRECCT 01 75 (Records in file 373)
FSTCLPT 00 00 Dunno
FSTRECFM c6("F" fixed record format)
FSTFLAGS 00
FSTLRECL 00 00 00 50 (Record length 80 bytes)
FSTBLKCT 00 08 (800? byte block count)
FSTYEARW f8 f4 (Year written: 84)
... bit of a jump here ...
FSTDATEW 12 05 (Date: December 05)
FSTTIMEW 12 31 (Time: 12:31)
?00 00 01 3b Dunno
FSTADBC 00 00 00 08 (should be same as FSTBLKCT for small files)
FSTAIC 00 00 01 75 (should be same as FSTRECCT for small files)
FSTNLVL 01Dunno
FSTPTRSZ 04Dunno
FSTADATI f8 f4 12 05 12 31 21(Alternate date/time: 841205 12:31:21)
The next part seems mangled to me. The first part of a filename seems to be
missing.
? 00 00 00 00
? e4 e3 c5 40 e2 c1 e2 c6 c9 d3 c5 40 (incomplete filename?)
? 00 00 00 00
? c3 c8 c5 c3 d2 f1 40 40 d7 e2 c1 e2 40 40 40 40 c1 f1 (complete filename)
Regards,
Peter Coghlan
>
> TIA
> Chuck
>
