Using the prop as a slowish FPGA...

Cluso99 · 2013-06-30 19:46

It struck me this morning that a prop can be used as a slowish FPGA with/without the other prop's abilities.

I cannot recall anyone mentioning this before???

How...
Well, take a cog and program it in spin to repeat a loop where outputs are a function of inputs. For speed, you could do this in pasm. Each fpga block could be done in a different cog if speed is an issue.

Really, what we do with objects is not that much different to implementing it in an fpga - just the language is different, and of course a software implementation is slower.

Here are some simple samples...

' 3 input AND gate
  repeat
    A := B and C and D

' 3 input OR gate
  repeat
    A := B or C or D

' more complex gates
  repeat
    A := (A and B) or C

Dr_Acula · 2013-06-30 19:59

Do we need some sort of program to translate Verilog into Pasm?

I've been playing around with VHDL and Verilog http://en.wikipedia.org/wiki/Verilog

It may not be too hard to do.

Oops, sorry. It would be absolutely impossible on the Propeller

Heater. · 2013-06-30 20:11

I always thought the idea of "software as silicon" on the Propeller covered this case as well. It has been discussed here many times over the years although perhaps with out actually saying "Prop as FPGA" or looking at such fundamentally simple logic as an example.

"Software as silicon" is a catch phrase used by XMOS in describing it's multi-core, timing deterministic processors and the same applies to the Propeller.

jmg · 2013-06-30 20:24

Cluso99 wrote: »

It struck me this morning that a prop can be used as a slowish FPGA with/without the other prop's abilities.

I cannot recall anyone mentioning this before???

How...
Well, take a cog and program it in spin to repeat a loop where outputs are a function of inputs. For speed, you could do this in pasm. Each fpga block could be done in a different cog if speed is an issue.

This is another application area that needs a language between Spin and PASM.

For real-world logic replacement, the final code needs to reside in COGs and be easily cog-split, as needed.

A natural extension from Boolean equation entry is to allow PLC like operation, and here a compiler could follow an existing PLC-specific language like :

http://en.wikipedia.org/wiki/IEC_61131-3

or it may be able to be based on a defined subset of existing 'simpler' languages like
http://www.freebasic.net/wiki/wikka.php?wakka=CatPgFullIndex

Cluso99 · 2013-06-30 20:29

heater: Yes. I don't think is has been said "Prop as FPGA" and fundamentally simple logic. What we do is way more complex than that because we add software with the logic.

Latches can be done by using internal variables and saving/latching them on an edge or level.

Dracula: I think Verilog/VHDL is much more complex than what I am thinking of. But maybe there could be translation/compiler software - but of course its IMPOSSIBLE

Cluso99 · 2013-06-30 20:32

jmg wrote: »

This is another application area that needs a language between Spin and PASM.

For real-world logic replacement, the final code needs to reside in COGs and be easily cog-split, as needed.

A natural extension from Boolean equation entry is to allow PLC like operation, and here a compiler could follow an existing PLC-specific language like :

http://en.wikipedia.org/wiki/IEC_61131-3

or it may be able to be based on a defined subset of existing 'simpler' languages like
http://www.freebasic.net/wiki/wikka.php?wakka=CatPgFullIndex

Implementing PLC has often been mentioned, but to my knowledge no-one has done it. Perhaps it's also IMPOSSIBLE

KeithE · 2013-06-30 20:51

On the other hand, here's an extract of the Virtex 6 FPGA manual - we use these at work to emulate ASICs:

"Each DSP48E1 slice fundamentally consists of a dedicated 25

Dr_Acula · 2013-06-30 20:55

Latches can be done by using internal variables and saving/latching them on an edge or level.

This is a D latch in verilog. Output Q follows the input D and it is stored on the positive going edge of a clock. One would need another hidden variable to store the previous state of the clock so you could detect the positive edge.

reg q;
always @(posedge clk)
  q <= d;

I think fpga IDEs like Quartus can convert schematics to verilog. So you could draw a schematic, convert to verilog, convert to pasm, and 'program' a propeller using schematics.

Completely crazy. And impossible.

Beau Schwabe · 2013-06-30 21:03

I think the best approach for something like this, especially with a multiple gate scenario, is to base the input and output around a state machine. Some functions/gates could be offloaded by the counters, but for more complex logic tables a state machine might be the way to go.

rod1963 · 2013-06-30 21:16

Certainly doable. Software will be the hard part, simulation and verification will be a must have.

Cluso99 · 2013-06-30 21:30

Beau Schwabe (Parallax) wrote: »

I think the best approach for something like this, especially with a multiple gate scenario, is to base the input and output around a state machine. Some functions/gates could be offloaded by the counters, but for more complex logic tables a state machine might be the way to go.

Nice thinking Beau!

BTW That signature quotation is a gem

Asked about the ramifications of his discoveries, Hertz replied, "Nothing, I guess." Hertz also stated, "I do not think that the wireless waves I have discovered will have any practical application."

jmg · 2013-06-30 21:31

Beau Schwabe (Parallax) wrote: »

I think the best approach for something like this, especially with a multiple gate scenario, is to base the input and output around a state machine. Some functions/gates could be offloaded by the counters, but for more complex logic tables a state machine might be the way to go.

State engines are quite powerful and usually easy to follow.

The CUPL Language (PLD) syntax goes like this

SEQUENCE DiQ  {  
	PRESENT 'h'0 IF Div10 & !Div2  NEXT 'h'1;
	             IF !Div10 & Div2  NEXT 'h'c;
			 DEFAULT NEXT 'h'0;
...
	PRESENT 'h'c IF Div10 & !Div2 NEXT 'h'0;  
	             IF !Div10 & Div2  NEXT 'h'4;
	             DEFAULT NEXT 'h'0;
      }

In a more conventional uC language, a Looping case statement with a Case variable (likely enum ) would be used.

The FreeBasic syntax for CASE is here

http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgSelectcase

Phil Pilgrim (PhiPi) · 2013-06-30 21:39

Ladder logic (i.e. PLC language) for the Propeller has already been done:

http://forums.parallax.com/showthread.php/121404

The last link in that thread will take you to a post that includes the actual code. Also "Search" on picoplc to find more threads that discuss this program.

For the uninitiated, ladder logic is very close to being a state-machine description of a system.

-Phil

Toby Seckshund · 2013-06-30 23:54

I thought it was just me having another daydream when I thought of the Prop as being akin to FPGAs. With my fixation to resurect my much missed Nascom i had done bits of it and then got distracted or wished that it could somehow be condensed into one (or less) IC(s). The answer was that the Prop and a couple more bits could, and has done. I beleive that the initial work on designs for the Props is on rather tasty FPGAs and so I guess that would flavour the end results. I must get around to using a Prop as all of the periferal to a real Z80

I am switching over from playing with Xilinx bits to Altera bits as I have found a load of scrap stuff that has MAX, FLEX, APEX and Cyclone(1)s. I have started a QFP208 board and to get around the 0.5mm pitch I have lifted alternate pins, some to go to an upper layer, and the others to go to the lower layer. A bit like through-hole surface-mount ... with a big hole ;-)

Heater. · 2013-07-01 02:50

Toby,

Yes, the real Z80 plus Propeller plus RAM idea was where we started all those years ago. I still think it is something that just has to be done.

But, damn it, I just discovered that an electronics store near here has a stock of original Motorola 68000 processors which they are selling at 1 Euro each.

You know what that means...68000 plus Propeller 2 module with it's 32MB of SDRAM....

Toby Seckshund · 2013-07-01 04:42

Heater.

i was thinking that the Prop(1) could be the Z's RAM as well. If you got used to the initial 1K user Ram, and then caused intense jealousy by being the first of the group to 16K ... who needs more than 16K????

I still have a load of "61256" SRAMs along with one 6116 I think it was the lack of 4118 ram and the resultant costs that did for Nasco. I saw some 4116 DRAMs the other day but the gits wouldn't let me have them. They are probably landfill now.

Heater. · 2013-07-01 04:57

Must have 64K. Can't run CP/M much without it.

What about using a Z80 plus three or four Prop 1 ?

Have each Prop serve up 16K of it's RAM for the Z80 and still have a load left over to make them useful as peripherals. Terminal, sound, SD card etc etc.

TinkersALot · 2013-07-01 06:49

and for a very slowish fpga perhaps the code generator could just generate c-enough dialect to run in pico-c here:

http://forums.parallax.com/showthread.php/148418-Pico-C?highlight=picoc

localroger · 2013-07-01 18:24

Heater. wrote: »

Must have 64K. Can't run CP/M much without it.

What about using a Z80 plus three or four Prop 1 ?

Have each Prop serve up 16K of it's RAM for the Z80 and still have a load left over to make them useful as peripherals. Terminal, sound, SD card etc etc.

This might be a stupid question since I haven't paid much attention to ZiCog, but considering that many of those early systems ran at 1 MHz is there any reason it would be impractical to use one Prop running ZiCog with a couple of 32K SPI RAMs supplying the Z80 RAM and the rest of the Prop's cogs doing peripheral stuff?

kwinn · 2013-07-01 19:44

Heater. wrote: »

Must have 64K. Can't run CP/M much without it.

What about using a Z80 plus three or four Prop 1 ?

Have each Prop serve up 16K of it's RAM for the Z80 and still have a load left over to make them useful as peripherals. Terminal, sound, SD card etc etc.

Now there is an intriguing idea. I still have several systems under contract that use the same Z80 board, and some of the parts are becoming very hard to find as well as being pretty expensive.

Heater. · 2013-07-01 22:37

Localroger,
ZiCog development has been on hold for a long while during which time propgcc has appeared and with it a whole slew of new external memory options and cached drivers for them.

So yes, adapting ZiCog to those new solutions has exactly been on my mind. As has reimplementing all the Spin parts in C.

Of course there is also the Prop II comming which will not need external RAM for running CP/M.

Dr_Acula · 2013-07-02 01:19

So yes, adapting ZiCog to those new solutions has exactly been on my mind. As has reimplementing all the Spin parts in C.

Well if you are going to do that sort of clever boffinry, then I guess we should think about running a Z80 emulation using the same external cached ram chips. Add one of the new wizzo 8 pin SPI ram chips and the cache driver from gcc, and I think it might be up to 10x faster than some of the parallel latch solutions we had.

And sorry cluso for turning your fpga thread into a Z80/Zicog thread. To move back on topic, once that new Z80 emulation is working, then next step would be to write a Verilog to C (addit - google says already done) translation and run it using something that ran under CP/M, like BDS C. Then you could have a fpga running in CP/M which is in turn running on the propeller.

It would satisfy the criteria of this original post in that it would be 'slowish'

Toby Seckshund · 2013-07-02 02:09

Sorry, it was me that brought up the Z80 specter. At least the Prop would be similar to the ULAs (ASIC?) that Sinclair stuff used, which was a PGA of sorts, many moons ago.

Heater. · 2013-07-02 03:24

Well, when we talk about a Z80 or other processor plus RAM plus Prop then the Prop is the "glue" that holds it all together. Mopping up glue logic has been a traditional use of programmable logic from the days of PALs onward to FPGAs.

Replace the real CPU and put an emulation in the Prop and we are in the realm of big FPGAs being configured with CPU cores written in VHDL/Verilog. Much like the current Prop II core in a Cyclone that is available.

It's all on topic:)

David Betz · 2013-07-02 05:21

Heater. wrote: »

Well, when we talk about a Z80 or other processor plus RAM plus Prop then the Prop is the "glue" that holds it all together. Mopping up glue logic has been a traditional use of programmable logic from the days of PALs onward to FPGAs.

If you're looking for a project that uses the Propeller as glue logic as you suggest, this one is pretty nice although it uses a 6502 instead of a Z80.

http://www.brielcomputers.com/wordpress/?cat=17

Martin_H · 2013-07-02 06:15

David Betz wrote: »

If you're looking for a project that uses the Propeller as glue logic as you suggest, this one is pretty nice although it uses a 6502 instead of a Z80.

http://www.brielcomputers.com/wordpress/?cat=17

That Apple I replica is neat and his use of a Propeller as the video hardware is pretty clever. During the late 70's to early 80's I was squarely in the 6502 microcomputer camp. So I'm fairly ignorant of CP/M or the Z80.

On topic. Isn't software sort of the ultimate FPGA? I would think that any logic layout you could conceive of would have an equivalent program that does the same thing.

Heater. · 2013-07-02 06:37

The Briel machine is a wonderful thing. However I never had any dealings with any Apple machines, they are not part of my history. I'm a product of the CP/M world.

Clearly anything we can specify as a program we can specify as a hardware logic design and vice versa. After all when it comes to actually making the thing work it's all just a bunch of logic elements anyway.

Vbriel · 2013-07-02 10:15

Actually, I did the Altair micro (currently out of stock) and added a RAM drive board that gives CP/M. I emulated the 8080 using a ATmega8515 but I use a Propeller as an onboard terminal and SD file handler. The 8080 was my first CPU emulation and I've never programmed on the 8080 before the project

The hard part was not only emulating the CPU instructions but emulating the front panels ability to single-cycle through an instruction. Very rewarding when it worked.

http://www.brielcomputers.com/wordpress/?cat=18

The replica 1 only interfaces with the 6821 (Peripheral Interface Adapter PIA) to the propeller chip so it isn't really glue logic. I have however been working on a project that uses the Propeller as video RAM to directly address the 6502 address bus to a Propeller as random access video. I choose to use a 65C02 at 3V so I could skip all the resistors for voltage level transition. I've been working with Jac Goudsmit and he really helped me with the video driver code. Using another cog, I was able to use the Propeller to emulate the boards ROM thus booting from the Propeller memory and driving the 1 MHz clock with the Propeller as well.

I need to get everything together in a generic format for release. I'm sure others may want to use the code for other things.

Publison · 2013-07-02 13:17

Vbriel wrote: »

Actually, I did the Altair micro (currently out of stock) and added a RAM drive board that gives CP/M. I emulated the 8080 using a ATmega8515 but I use a Propeller as an onboard terminal and SD file handler. The 8080 was my first CPU emulation and I've never programmed on the 8080 before the project The hard part was not only emulating the CPU instructions but emulating the front panels ability to single-cycle through an instruction. Very rewarding when it worked.

http://www.brielcomputers.com/wordpress/?cat=18

The replica 1 only interfaces with the 6821 (Peripheral Interface Adapter PIA) to the propeller chip so it isn't really glue logic. I have however been working on a project that uses the Propeller as video RAM to directly address the 6502 address bus to a Propeller as random access video. I choose to use a 65C02 at 3V so I could skip all the resistors for voltage level transition. I've been working with Jac Goudsmit and he really helped me with the video driver code. Using another cog, I was able to use the Propeller to emulate the boards ROM thus booting from the Propeller memory and driving the 1 MHz clock with the Propeller as well.

I need to get everything together in a generic format for release. I'm sure others may want to use the code for other things.

Vince,

Thanks for joining us and sharing your useful information. I visit your website often.

Jim

Toby Seckshund · 2013-07-02 13:21

The only Z80s I have are the CMOS sort and should run faster than the "real" 2.5MHz and "never ran properly, for me" 4MHz ones. I have often wondered what speed the newer ones would trundle along at given 3.3 Volts to play with. As long as the Prop told the Z80 to wait things should be OK. The Prop could dynamically ramp up and down the clock rate too.

I got infected with Z80itis as my first computer used that, wheras the USA side got the 6502 which I never tried to learn much about, even though I did have a C64, C128 and a BBC B (without the add on PCB). I know that the C64 used interleaved access to the RAM so that got some speed back so that should be just what the HUB ordered.

Alan

Cluso99 · 2013-07-02 19:18

While some of the discussion may be a bit OT, I am not concerned at all. Its all generally about what the prop can do and has done. A lot of this while not specifically implemented as FPGA, it is a replacement for what could be done on an fpga.

I still have RamBlades and every now and then I play with them, and the OS (FAT16/32) that coexists with it. FTF works 3 of the 4 directions (fat to cpm incomplete). I have often looked at speeding up the ZiCog emulation using mixed variations of overlays and LMM. There are other things that could be done too. While a few Z80 opcodes are not implemented or faulty, the other Z80 implementation (by ??? - my memory fails me) does fix this. IMHO the SPI implementations are just not going to cut it for speed on the P1. My RamBlade implementations use a separate prop for the I/O via high speed serial. My smallest is 2x 1"sq pcbs that stack - basically a whole CP/M machine in 1"x1"x0.4"h with either a serial port or a PS2 keyboard and monochrome composite video interface. Of course it also runs my PropOS (FAT16/32) as well as Catalina. In fact I run a huge Catalina C program on this block in a commercial product. (for those who know me, I didn't write the C program).

Using the prop as a slowish FPGA...

Comments