FPGA experiments
prof_braino
Posts: 4,313
We can now implement a prop chip in FPGA. What are some experiments folks can try? Could we :
Would these be primarily dependent on the resources of the FPGA, or would these require Chip Gracey level expertise?
Not that I would try to mod the P1 as my first FPGA project. But I would be interested in a whole bunch of cogs and ram.
- Have more than 8 cores? 16, 32, or 64?
- Have more than 32k RAM? 1 meg?
- More than 32 I/O pins? 64 (32A and 32B)? More than 64?
Would these be primarily dependent on the resources of the FPGA, or would these require Chip Gracey level expertise?
Not that I would try to mod the P1 as my first FPGA project. But I would be interested in a whole bunch of cogs and ram.
Comments
- all of your bullets are FPGA resource bound
- more cogs would slow down hub access
The I/O and memory would be the easiest mods.
Thanks for the response!
Anybody have a guestimate as to which, if any, of the FPGA boards being discussed, would support:
64 I/O pins
1 meg of RAM
double the number of P1 cogs? (assuming the hub access issue is not the primary concern)
Are any of these straight forward parameter changes or are they all brain surgery?
Brain Surgery of varying degrees, I imagine
It is interesting but like you say mostly academic. Maybe a training course for the P3 "Community Propeller"?
I'll switch back to P2 as soon as there is something to run.
It seems to me, as a learning vehicle, modifying P1 is a good thing. It may well put the P2 work into better context for everyone too. People may understand the impact of changes better, which may lead to better ideas in the future.
Could be some P1 based design does end up in a chip. Older processes aren't as expensive. It really could be worth kickstarting a P1 that has a small ROM, 64 I/O's, multiply, etc...
And if we do something really imaginative, it could find its way into the P2.
And sooner or later there may be a P1B and some of these newfound experiments could find their way into that.
In the meantime, we can all have fun, and try things without interrupting Chip. And in the process, we are learning Verilog and which FPGAs work best with this design.
I suggest initially we keep it to the upper part of the 64KBhub so we can keep compatibility.
We just require the booter and spin. I want to replace the spin interpreter with my faster version as soon as I get time.
We also want to max the hub ram above 32KB. Might be good to see if we can define the hub as all ram, and preload the top part from the file on bootup.
Next would be to mod the booter to load 64KB (or maybe slightly less so the booter and spin does not get destroyed)
There are just so many possibilities here. What to try first???.
The low rom suggestion was due to the 512 long hubexec hub blind spot for cog addresses. I still intend to do that until I get segment registers working.
Then more small steps, no huge changes for now. Port B for sure. Maybe a debugger? Different hubexec experiments? The sky is the limit.
Long term, I intend to put a boot rom at $FFFF0000, possibly booting directly from a uSD card, or an SPI flash. Perhaps 4K - 8K, with a monitor.
Basically, I see the P1V (Propeller 1 Verilog) as a great way of experimenting, and learning more about designing processors in Verilog.
I love the freedom of trying really wild ideas simply by implementing them myself in FPGA form!
FedEx tracking says my CV's are in Vancouver... I should get them Monday or Tuesday.
I have also looked at adding more hub ram, and making 64 I/O. The I/O has some ramifications though.
Bill,
Yes, small ROM at the top of the 64KB hub $FFFF0000 makes sense. It needs to be $FF9F0000or wherever both the booter and spin live - ie Use the same entry addresses as the P1.
We also need to remove the encryption so we can make the ROM booter easily.
I have my P2 debugger which I made sure it was almost P1 compatible when I did it. That plus Chips monitor from the P2 will be a nice addition.
Anyone,
Can we make the hub RAM and still preload it from a file as Chip is doing it for the ROM?
Yes you can. Just use the same directive that inits the ROM - (* ram_init_file = "hub_rom_high.hex" *) but with the appropriate filename.
BTW Welcome to the forum. Are you going to join us with experimenting?
Welcome!
Great to see another Brit on the forum.....
OF course, if you're already working on P2 don't stop. But the purpose of open source is to allow folks to attempt imporvements, yes no?
And no one should bother thinking about converting any design into a chip until the design is demonstrated to have some benefit not available in current offerings.
That being said, variations in FPGA might be a way to try the various permutations that have been discussed, to see if any of those have utility in ways not imagined by CG. While most mutations are not viable, 1 in 1000 (is that right?) might be superior. It the weird experiemnts (by folks that don't understand enough to know in advance that it will fail) that uncover radical interesting new information. Just because something is impossible is no reason not to do it anyway.
Folks interested in P2 development are interested in P2 development. Other folks might want P1 with 64 cores and/or 1 meg of RAM.
If I had more cores and more ram, I might do stuff that that could be interesting.
Low hanging fruit and all.
I plan to use $FFFF0000 then map it into wherever the legacy code wants it using DSEG, but it could be anything WAY the heck up in the potential 32 bit address space.
Totally agred about removing encryption P1V experiments, it just slows down the dev cycle. Due to FPGA costs, I really doubt P1V's will show up on commercial boards.
I am looking forward to your debugger running on P1V, along with a port of Chip's monitor.
Thanks for the welcome an yes I'm going to be experimenting. I'll post some details to the relevant threads soon - we've had guests for a few days so not much time to play
Thanks! Don't we outnumber the Americans here then?
I suspect you guys are going to learn logic design and will be coming up with all kinds of ideas which will find their way into future chips.
It must be kinda exciting to see it grow in different ways...
I don't know what's going to happen, but I think a lot of people will discover that designing hardware is fun, which will be a good outcome. It takes a few months for the hardware design mindset to take hold, after having done only software. It's a big adventure.
I don't expect that we will get a new chip design from what we are doing, but I do agree that some parts will be taken on board for another design, be it P1B or P2 or P3.
And in the process, we will have learnt heaps. And I have already in the past few days... just reading the code I learnt a lot.
Actually, thinking a little deeper about all this. I know someone who has a possibility of altering the code and getting Parallax to fab a new P1X specifically for them.
Definitely fun times ahead!
That would be a tricky target to hit, as much of the P1 is hand crafted, and so a merge of Custom + Synth Logic would be a tough call.
What may be practical would be an ASIC style synth, with minimal Analog - so the Pin-ADCs would go, and maybe the PLLs (PLL may be common enough, an IC vendor has a standard, tested cell )
Clock generator ICs are getting smaller and cheaper, so it may be the PLL issues can be side-stepped on a custom pass.
(I'm guessing they are not price-paranoid, if they are looking at running their own silicon ?)
I've been meaning to do some "real experiments" with my FPGA boards... and this motivates me greatly. I wanted to keep my DE2-115 free for P2 testing, but wanted more memory, so I should be receiving my two shiny new BE CV's tomorow (latest Tuesday) :-)
Kudos to you, Ken, and the rest of Parallax for releasing the Verilog files.
I have built products that would only be used once to transfer data from one computer to another. Pricing was never really an issue (but I didn't gouge either, just an excellent ROI and both sides were happy). They just needed to transfer the files overnight to go live on a new system. The vendor suggested they re-key their database... can you image the downtime as well as errors!