These fpga boards are cheap - under $20 on ebay. Rough ballpark they have enough to do a Z80, some internal ram, VGA or TV display, two uarts, external ram (512k), SD card, and spare pins for external I/O. This uses about 18% of a cyclone II. A cog might be similar to a Z80 in terms of LEs, - not sure about that. There are things that are done on the propeller that take a cog that could be done in fgpa hardware - eg uarts and displays. There are also some intriguing possibilities with SD card - a full installation of Kye's SD driver for instance takes about half the propeller ram, and on a fpga this can all be done in the gate array leaving the software very simple to write and freeing up lots of memory for code.
The nano boards look like they are high end. The cyclone II board is right at the other end - possibly considered ancient - but at the same time that means inexpensive. There might be other boards somewhere in the middle that could do this emulation. I'm looking through the overview section of the Altera chips eg http://www.altera.com/devices/fpga/cyclone2/overview/cy2-overview.html
Having got deep inside vhdl (and I guess verilog would be similar), there are some intriguing possibilities hybridising things together. Why not a propeller and Z80 hybrid?!
I wonder if a two cog propeller with external ram (eg 512k) could fit on a cyclone II board?
..The cyclone II board is right at the other end - possibly considered ancient - but at the same time that means inexpensive.
I wonder if a two cog propeller with external ram (eg 512k) could fit on a cyclone II board?
Those cheap boards also lack a loader, (need external pgmr cable) and their RAM is only ~14.9kB, but it should be easy to see what does fit into that. Certainly, external RAM is quickly needed.
Another candidate at the smaller (fractional P1) end, would be the MachXO2, maybe XO2-7000
That has ~ 240kb of RAM, 6864 LUT, and has the flash included, so is instant on.
It has a EVB LCMXO2-7000HE-B-EVN, 1 $25.91 which includes a FT2232H loader and comm channel.
(So should be able to load the fP1 on the 2nd comm port )
Even smaller and cheaper again, is the Lattice iCE5LP4K (3520 LUT 80kbit) - has a tiny package, few pins, but there may be a niche for that.
Perhaps a iCE5LP4K could couple with a QuadSPI bus, for execute in place ?
I have been playing around with vhdl and verilog. Be warned - it is highly addictive! But great fun too.
Looking at the source for the Propeller I, it is very similar to the Z80 computer emulation. Cogs seem simpler than a Z80 - more on a par with an 8080. I am going to see if I can get a cog going inside my Z80 computer. Biggest problem might be that I've been coding in vhdl and this is verilog. But they are rather similar and I think there are programs around that can do the conversion.
I think a lot of these fpga chips have 18 bit hardware multipliers. They could be useful - define some ports which exist internally, write out two 18 bit numbers and read back the result.
Re internal vs external ram, the lower priced fpga chips tend to have less ram. External ram is easy to add, but for a propeller running multiple cogs all the cogs need to talk to their ram in parallel, so this is where internal ram in a fgpa is much better than the same amount of external ram. However, for one cog the external ram would work well.
Best way to learn vhdl/verilog IMHO - jump into an existing design and start modifying it.
On the Z80 emulation, one of the things I did once I learned enough vhdl to be dangerous was I added banked memory support. So with one 512k memory chip it is possible to switch in and out banks of 4k. This should work too for a propeller - you can swap blocks in and out. On the Z80 what we have been doing is getting MP/M (multi user DOS like operating system) and also a ram disk.
I can see some useful synergies with the propeller. Basically, two of the frustrations I found with the PI was that a) I kept running out of memory and b) not enough pins. FPGA emulations can solve both of those problems.
Banked memory can be addressed using virtual ports, and this means you don't necessarily need new pasm instructions (for the Z80 emulation, you can't go adding instructions here and there, so you have to find a solution that uses existing instructions). So you can output to these virtual ports (which exist inside the fpga chip but never come to physical pins) and expand memory that way.
So for instance, you might have a font which takes 50k of space, and you can store that in a ram chip, and very quickly switch in the bank of memory that has the font data for a character - fast enough to be changing the banks for each character that is being printed, and still be working within a 32k code space.
The nano boards look like they are high end. The cyclone II board is right at the other end - possibly considered ancient - but at the same time that means inexpensive.
DE0-nano is now cheap low end board It is a cheapest FPGA board I can get here and it is easy available.
The Cyclone II is EOL now. The new Quartus software doesn't support Cyclone II and Cyclone III. And after I did some (small!) projects for Cyclone IV I realized I cannot move them easily to Cyclone II - its PLL was too weak and I had to make some additional coding to get frequencies I needed.
The nano boards look like they are high end. The cyclone II board is right at the other end - possibly considered ancient - but at the same time that means inexpensive. There might be other boards somewhere in the middle that could do this emulation. I'm looking through the overview section of the Altera chips eg http://www.altera.com/devices/fpga/cyclone2/overview/cy2-overview.html
I recently got one of these Cyclone IV boards, which are good value:
Yeah. Wow. I just read through, and expected a little better.
I was actually there on the site before user registration became mandatory. Had some emails with Rob Malda when he was still running it off some Alphas he got hold of for a song too. That site was pretty awesome for a while. Miss it.
My low UID is good for some quick attention, but I don't participate there as much anymore. Lots of smart minds moved on.
I have a Slashdot ID in the low 5 digits dating from 1997. I have long since forgotten the password and don't have whatever email address I used back then so I can't get back in there.
Maybe I was more easily impressed back then. I seem to remember some quite well know people used to chime in there. I was new to Linux and this weird Free Software idea so I picked up a lot of info on nerdy Linux stuff.
Now it's a waste of time to do anything more than scan the stories occasionally. Mostly I'm disappointed with results of doing even that.
Me too. And yes, I got into OSS partially due to /. It was a different time. There were some great discussions, and the news was relevant to nerdy people with an OSS leaning. Now it's just stuff. Not even stuff that matters so much. In any case, I typically can get a submit through, so I did. Getting the word out means getting the word out.
Thanks for this Parallax! Wasnt enough time in the day before. Now more reading and studying and playing. Unfortunately I am not a programmer only a dabler. :nerd:
So much to learn so little time. Have been interested in FPGA for a long time. My board will be here next week!!
This isn't the place or thread for code-style holy wars. I'm just going to point out two things with respect to re-formatting the code:
0) We can no longer diff against the original parallax sources because every line is different.
1) You just disrespected Chip by attacking his formatting choices and, more importantly you are now forcing him to **alter his** coding style to match yours if he is going to contribute.
Same with cuddled / uncuddled braces, variable naming conventions - none of it really matters compared to interoperability and consistency.
Mass formatting breaks collaboration.
Honor the formatting choices of the original author because none of it really matters as much as the ability to work together.
This isn't the place or thread for code-style holy wars. I'm just going to point out two things with respect to re-formatting the code:
0) We can no longer diff against the original parallax sources because every line is different.
1) You just disrespected Chip by attacking his formatting choices and, more importantly you are now forcing him to **alter his** coding style to match yours if he is going to contribute.
Same with cuddled / uncuddled braces, variable naming conventions - none of it really matters compared to interoperability and consistency.
Mass formatting breaks collaboration.
Honor the formatting choices of the original author because none of it really matters as much as the ability to work together.
I think if all that is done is replacing tabs with the appropriate number of spaces so the code looks identical then it shouldn't causing any diff problems since most diff programs can be told to ignore differences in white space.
On the subject of format changes, am I the only person who suffers with utf-16 to utf-8 conversion (most propeller code appears to be utf-16). I use iconv to convert it but many unix tools choke on it and github (for example) won't display it.
Honor the formatting choices of the original author because none of it really matters as much as the ability to work together.
That is exactly why I am begging and pleading for Chip to kick off a formal repository with no tabs. The formatting does not visibly change for him so it does not impose any altering of style aesthetically. It does ease collaboration into the future.
Yes, many diff programs can ignore white space changes. Which has it's own downsides. As we all know white space change can change semantics in languages like Spin and Python and surprisingly JavaScript in subtle ways. Also it means that developers can sneak crappy formatting style into your code with out it being noticed when looking over patches.
Oh my God yes, that utf-16 utf-8 thing is a nightmare. Quite frankly I think anything more than ASCII should be banned from source code. In fact unicode itself should be banned completely. Have you ever noticed that there are an increasing number of web pages containing "funny" characters or become totally unreadable, mostly due to some error in translating from one representation to another. We are slowly rotting all our information with this unicode non-sense.
We seem to be a bit stuck with it as Spin includes the wacky idea of supporting drawing diagrams in the source with graphic characters. Which of course never renders correctly anywhere out side of Spin tool....
Hi.
I might have fool question because I'm biginner about FPGA.
I think velilog code include spin.
I usually use propforth.
But free-space is small because spin occupy 32k.
Propeller's RAM(64k) on FPGA is possible to be free?
And loading propforth to RAM is possible?
Great that Parallax open-sourced the P1 design. I've seen it in my various news sources and "liked" or "+1'd" it many times.
I would love to find some time to get familiar with Verilog, buy a cheap FPGA board (not one of those $600 ones) and get busy trying to get a "PropellerPlus" to work with 64 IO pins and 64K RAM and possibly debugging facilities.
I also have some thoughts about replacing some less-than-useful instructions by more useful ones (for example, replace MOVA, MOVI and MOVS by a single instruction, or instructions that do the opposite of those instructions), but I haven't looked at it yet and I don't know enough about Verilog yet.
I already starred Heater's Github repo, and I think using Github is an excellent idea. I use their Windows client and although it has its problems (for example every once in a while you have to go into task manager and kill ssh-agent because it uses 100% CPU, and the GUI is not exactly the fastest I've ever seen), it's very workable. Much better than what I've seen from Google Code. Also, making a Wiki and/or web page hosted by Github is very easy (just make a branch with the right name) and so is collaboration.
The only downside about this thread is that, as usual, it's turning into a hundreds-of-pages-long IRC chat again that's full of information but can only be accessed sequentially. I wish the moderators would do more to encourage people more to start new threads when they start a different subject (or even force them, by moving posts to new threads). "That'd be great, thanks!" as the meme goes.
You are right in that there is a 32K ROM area not writable on the normal P1. So RAM is only 32K.
But it is not all SPIN. The SPIN Interpreter is just 2K of it. It fits in a COG.
The rest are Font, and Sine/Log tables. There is also a amount of ~4K for booting and loading the Propeller.
In the FPGA Version you will be able to use some of that area as RAM. Some people are working on that already. But not all of the 64K. Some needs to stay.
The basic plan seems to be to have the upper 32K preloaded with the original ROM content, but being able to overwrite it with own data.
It might be possible to change the Verilog to preload PropForth into the FPGA. I do not know for sure since I do not use any Forth.
@Prof_Braino asked a similar question in another thread.
So my guess is that it is possible, but not done yet.
How is your dog(girl) doing? I have for the first time of my life two own dogs. Always took care of other people's dogs (vacation of owners/training).
The best decision I ever made. Usually I was very unfriendly in the morning. The dogs changed that. They make me smile all the time...
@msrobots,
I thanks for your reply.
I don't have ever known that spin interpreter is just 2k.
I'm going to study about FPGA.
BTW, my dog gets completely exhausted, because it is hot.
She is 10years and 8month now.
Maybe she will live until 15 years old.
We are together until then.
WOW, what I have missed being absent for a few years. The Prop 1 open source?
It is time to save up for an FPGA board for sure, with the Propeller 1 open source, and the Propeller 2 being tested in FPGA. I feel I have missed the world.
Time to look at what it would really take to implement Port B on the Propeller one, and how the pipeline could be modified to allow for single cycle instructions.
Cool, and kudos to parallax for taking this route to continuing the Propeller 1 development.
WOW, what I have missed being absent for a few years. The Prop 1 open source?
It is time to save up for an FPGA board for sure, with the Propeller 1 open source, and the Propeller 2 being tested in FPGA. I feel I have missed the world.
Time to look at what it would really take to implement Port B on the Propeller one, and how the pipeline could be modified to allow for single cycle instructions.
Cool, and kudos to parallax for taking this route to continuing the Propeller 1 development.
There are a lot of P1V versions lying somewhere. 4-cogs, more than 8 cogs, with PortB, MUL, etc. There was a subforum for this stuff, but it was gone with the new forum version (why?) and P1V related stuff was scattered on Propeller1 subforum. It is still here, but harder to find.
The P1V used in this project has a 96-bit PortB and mul implemented as normal 4-cycles instruction. It works @ 114 MHz - up to 120 MHz can be stable in DE@-115 (Cyclone 4), I also tried it on DE1-SOC with Cyclone V - this is faster, ~180 MHz available if I can remember correctly. Implementing mul allowed to run SIDCog at 64 kHz instead of 32 kHz, giving better sound quality.
It might be an interesting target for P1V. It's supposedly only $13. The FPGA is from a Chinese company Anlogic and I believe that they are located in Shanghai. I only mention this because some documentation and tools might not yet be translated.
Interesting. The link from the to the Anlogic EG4S20BG256 datasheet did not work. Can't find it anywhere else either. Even http://anlogic.com/ does not work.
Comments
I see a figure of 15k LEs. A small cyclone II board is ? 5k, so it isn't going to fit a full propeller emulation.
Over the last 6 months a small group of us have been playing around with this circuit http://searle.hostei.com/grant/Multicomp/index.html
These fpga boards are cheap - under $20 on ebay. Rough ballpark they have enough to do a Z80, some internal ram, VGA or TV display, two uarts, external ram (512k), SD card, and spare pins for external I/O. This uses about 18% of a cyclone II. A cog might be similar to a Z80 in terms of LEs, - not sure about that. There are things that are done on the propeller that take a cog that could be done in fgpa hardware - eg uarts and displays. There are also some intriguing possibilities with SD card - a full installation of Kye's SD driver for instance takes about half the propeller ram, and on a fpga this can all be done in the gate array leaving the software very simple to write and freeing up lots of memory for code.
The nano boards look like they are high end. The cyclone II board is right at the other end - possibly considered ancient - but at the same time that means inexpensive. There might be other boards somewhere in the middle that could do this emulation. I'm looking through the overview section of the Altera chips eg http://www.altera.com/devices/fpga/cyclone2/overview/cy2-overview.html
Having got deep inside vhdl (and I guess verilog would be similar), there are some intriguing possibilities hybridising things together. Why not a propeller and Z80 hybrid?!
I wonder if a two cog propeller with external ram (eg 512k) could fit on a cyclone II board?
Those cheap boards also lack a loader, (need external pgmr cable) and their RAM is only ~14.9kB, but it should be easy to see what does fit into that. Certainly, external RAM is quickly needed.
Another candidate at the smaller (fractional P1) end, would be the MachXO2, maybe XO2-7000
That has ~ 240kb of RAM, 6864 LUT, and has the flash included, so is instant on.
It has a EVB LCMXO2-7000HE-B-EVN, 1 $25.91 which includes a FT2232H loader and comm channel.
(So should be able to load the fP1 on the 2nd comm port )
Even smaller and cheaper again, is the Lattice iCE5LP4K (3520 LUT 80kbit) - has a tiny package, few pins, but there may be a niche for that.
Perhaps a iCE5LP4K could couple with a QuadSPI bus, for execute in place ?
Anyway, now we have the new forum I will use that instead of clogging this thread.
http://forums.parallax.com/forumdisplay.php/101-Propeller-1-Verilog-Code-Development
I have been playing around with vhdl and verilog. Be warned - it is highly addictive! But great fun too.
Looking at the source for the Propeller I, it is very similar to the Z80 computer emulation. Cogs seem simpler than a Z80 - more on a par with an 8080. I am going to see if I can get a cog going inside my Z80 computer. Biggest problem might be that I've been coding in vhdl and this is verilog. But they are rather similar and I think there are programs around that can do the conversion.
I think a lot of these fpga chips have 18 bit hardware multipliers. They could be useful - define some ports which exist internally, write out two 18 bit numbers and read back the result.
Re internal vs external ram, the lower priced fpga chips tend to have less ram. External ram is easy to add, but for a propeller running multiple cogs all the cogs need to talk to their ram in parallel, so this is where internal ram in a fgpa is much better than the same amount of external ram. However, for one cog the external ram would work well.
Best way to learn vhdl/verilog IMHO - jump into an existing design and start modifying it.
On the Z80 emulation, one of the things I did once I learned enough vhdl to be dangerous was I added banked memory support. So with one 512k memory chip it is possible to switch in and out banks of 4k. This should work too for a propeller - you can swap blocks in and out. On the Z80 what we have been doing is getting MP/M (multi user DOS like operating system) and also a ram disk.
I can see some useful synergies with the propeller. Basically, two of the frustrations I found with the PI was that a) I kept running out of memory and b) not enough pins. FPGA emulations can solve both of those problems.
Banked memory can be addressed using virtual ports, and this means you don't necessarily need new pasm instructions (for the Z80 emulation, you can't go adding instructions here and there, so you have to find a solution that uses existing instructions). So you can output to these virtual ports (which exist inside the fpga chip but never come to physical pins) and expand memory that way.
So for instance, you might have a font which takes 50k of space, and you can store that in a ram chip, and very quickly switch in the bank of memory that has the font data for a character - fast enough to be changing the banks for each character that is being printed, and still be working within a 32k code space.
DE0-nano is now cheap low end board
The Cyclone II is EOL now. The new Quartus software doesn't support Cyclone II and Cyclone III. And after I did some (small!) projects for Cyclone IV I realized I cannot move them easily to Cyclone II - its PLL was too weak and I had to make some additional coding to get frequencies I needed.
I recently got one of these Cyclone IV boards, which are good value:
http://www.ebay.co.uk/itm/191129925298?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
It does require the purchase of a USB Blaster, unlike the DE0-Nano.
I'm not too happy about the apparent lack of decoupling on the FPGA, but it works OK.
It uses the smallest Cyclone IV, so won't accommodate the P1.
Yeah. Wow. I just read through, and expected a little better.
I was actually there on the site before user registration became mandatory. Had some emails with Rob Malda when he was still running it off some Alphas he got hold of for a song too. That site was pretty awesome for a while. Miss it.
My low UID is good for some quick attention, but I don't participate there as much anymore. Lots of smart minds moved on.
As far as I can remember it's never been any different.
I've always liked the articles and means of delivery, and almost never read any comments. It works.
Maybe I was more easily impressed back then. I seem to remember some quite well know people used to chime in there. I was new to Linux and this weird Free Software idea so I picked up a lot of info on nerdy Linux stuff.
Now it's a waste of time to do anything more than scan the stories occasionally. Mostly I'm disappointed with results of doing even that.
So much to learn so little time. Have been interested in FPGA for a long time. My board will be here next week!!
You got dropped on your head as a baby?
/jk
This isn't the place or thread for code-style holy wars. I'm just going to point out two things with respect to re-formatting the code:
0) We can no longer diff against the original parallax sources because every line is different.
1) You just disrespected Chip by attacking his formatting choices and, more importantly you are now forcing him to **alter his** coding style to match yours if he is going to contribute.
Same with cuddled / uncuddled braces, variable naming conventions - none of it really matters compared to interoperability and consistency.
Mass formatting breaks collaboration.
Honor the formatting choices of the original author because none of it really matters as much as the ability to work together.
On the subject of format changes, am I the only person who suffers with utf-16 to utf-8 conversion (most propeller code appears to be utf-16). I use iconv to convert it but many unix tools choke on it and github (for example) won't display it.
That is exactly why I am begging and pleading for Chip to kick off a formal repository with no tabs. The formatting does not visibly change for him so it does not impose any altering of style aesthetically. It does ease collaboration into the future.
Yes, many diff programs can ignore white space changes. Which has it's own downsides. As we all know white space change can change semantics in languages like Spin and Python and surprisingly JavaScript in subtle ways. Also it means that developers can sneak crappy formatting style into your code with out it being noticed when looking over patches.
Oh my God yes, that utf-16 utf-8 thing is a nightmare. Quite frankly I think anything more than ASCII should be banned from source code. In fact unicode itself should be banned completely. Have you ever noticed that there are an increasing number of web pages containing "funny" characters or become totally unreadable, mostly due to some error in translating from one representation to another. We are slowly rotting all our information with this unicode non-sense.
We seem to be a bit stuck with it as Spin includes the wacky idea of supporting drawing diagrams in the source with graphic characters. Which of course never renders correctly anywhere out side of Spin tool....
Didn't want to de-rail this thread any longer...
I might have fool question because I'm biginner about FPGA.
I think velilog code include spin.
I usually use propforth.
But free-space is small because spin occupy 32k.
Propeller's RAM(64k) on FPGA is possible to be free?
And loading propforth to RAM is possible?
I would love to find some time to get familiar with Verilog, buy a cheap FPGA board (not one of those $600 ones) and get busy trying to get a "PropellerPlus" to work with 64 IO pins and 64K RAM and possibly debugging facilities.
I also have some thoughts about replacing some less-than-useful instructions by more useful ones (for example, replace MOVA, MOVI and MOVS by a single instruction, or instructions that do the opposite of those instructions), but I haven't looked at it yet and I don't know enough about Verilog yet.
I already starred Heater's Github repo, and I think using Github is an excellent idea. I use their Windows client and although it has its problems (for example every once in a while you have to go into task manager and kill ssh-agent because it uses 100% CPU, and the GUI is not exactly the fastest I've ever seen), it's very workable. Much better than what I've seen from Google Code. Also, making a Wiki and/or web page hosted by Github is very easy (just make a branch with the right name) and so is collaboration.
The only downside about this thread is that, as usual, it's turning into a hundreds-of-pages-long IRC chat again that's full of information but can only be accessed sequentially. I wish the moderators would do more to encourage people more to start new threads when they start a different subject (or even force them, by moving posts to new threads). "That'd be great, thanks!" as the meme goes.
===Jac
You are right in that there is a 32K ROM area not writable on the normal P1. So RAM is only 32K.
But it is not all SPIN. The SPIN Interpreter is just 2K of it. It fits in a COG.
The rest are Font, and Sine/Log tables. There is also a amount of ~4K for booting and loading the Propeller.
In the FPGA Version you will be able to use some of that area as RAM. Some people are working on that already. But not all of the 64K. Some needs to stay.
The basic plan seems to be to have the upper 32K preloaded with the original ROM content, but being able to overwrite it with own data.
It might be possible to change the Verilog to preload PropForth into the FPGA. I do not know for sure since I do not use any Forth.
@Prof_Braino asked a similar question in another thread.
So my guess is that it is possible, but not done yet.
How is your dog(girl) doing? I have for the first time of my life two own dogs. Always took care of other people's dogs (vacation of owners/training).
The best decision I ever made. Usually I was very unfriendly in the morning. The dogs changed that. They make me smile all the time...
Enjoy!
Mike
Enjoy!
Mike
I thanks for your reply.
I don't have ever known that spin interpreter is just 2k.
I'm going to study about FPGA.
BTW, my dog gets completely exhausted, because it is hot.
She is 10years and 8month now.
Maybe she will live until 15 years old.
We are together until then.
Late to the party, looks cool enough for some inve$tigation....
How about a music synthesizer? I know Moog gets their keyboards from an Italian supplier, but haven't found out who.
PS: Where did all the P1V topics end up when the forums were changed?
They got mixed in with the Propeller 1 topics. But if you search for, or click on the #P1V tag, you'll find most of them, I think.
===Jac
It is time to save up for an FPGA board for sure, with the Propeller 1 open source, and the Propeller 2 being tested in FPGA. I feel I have missed the world.
Time to look at what it would really take to implement Port B on the Propeller one, and how the pipeline could be modified to allow for single cycle instructions.
Cool, and kudos to parallax for taking this route to continuing the Propeller 1 development.
Yes, and FPGAs continue to improve.
There was a release recently on Cyclone 10 parts, there is MAX 10, and Lattice have ECP5 & iCE40 UltraPlus...
http://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40Ultra.aspx
The newest of these have 128kBytes of SRAM and QFN48 packages, so are in microcontroller realm.
There are a lot of P1V versions lying somewhere. 4-cogs, more than 8 cogs, with PortB, MUL, etc. There was a subforum for this stuff, but it was gone with the new forum version (why?) and P1V related stuff was scattered on Propeller1 subforum. It is still here, but harder to find.
I made a retromachine with P1V: http://forums.parallax.com/discussion/157850/a-de2-115-propeller-retromachine-1920x1080-enabled/p1
The P1V used in this project has a 96-bit PortB and mul implemented as normal 4-cycles instruction. It works @ 114 MHz - up to 120 MHz can be stable in DE@-115 (Cyclone 4), I also tried it on DE1-SOC with Cyclone V - this is faster, ~180 MHz available if I can remember correctly. Implementing mul allowed to run SIDCog at 64 kHz instead of 32 kHz, giving better sound quality.
https://www.cnx-software.com/2018/09/04/licheetang-anlogic-eg4s20-fpga-board-targets-risc-v-development/
It might be an interesting target for P1V. It's supposedly only $13. The FPGA is from a Chinese company Anlogic and I believe that they are located in Shanghai. I only mention this because some documentation and tools might not yet be translated.
But they do have a git hub presence: https://github.com/AnlogicInfo