If though someone identifies a suitable FPGA such as the Lattice parts that will do a full P1+ then great, please let us know because I will also explore that option too.
If anyone has a Lattice 3.7 flow and P1V file sets for Lattice, they could build to check the LFE5U-12, & LFE5U-25 ?
Easy to say, but that, plus PLL and Crystal Support, are all outside of the P1V verilog files, so you are into Custom Design.
Interestingly I am quite happy to use one of the many cheap clock chips that are available these days, why do you need PLL when you can use these babies for about the same price as a rock!
Cluso said "There are a few bits not done - the security fuses, and the PLL's required for the counter/video, and perhaps 16x16 multiply and a divide???"
My personal view is this is exactly the sort of thing you don't want. None of those things. Just more pins and (maybe) more memory.
More pins - should be simple as the P1 software already planned for this with the second register set.
More memory. With the ever decreasing costs of chips and the age of the P1, surely it should be possible to have 64k or 128k for a similar price?
And that is it. Do nothing more. Any extra add-ons can be discussed over in the P2 forum.
And then a technical question for those doing the emulation - are there any instruction changes that are needed to address larger hub ram?
addit - @Cluso, I have been a bit busy lately, just set up a medical practice in the Aldinga shopping centre a few shops up from the newsagency. Means even less time for the prop
Cluso said "There are a few bits not done - the security fuses, and the PLL's required for the counter/video, and perhaps 16x16 multiply and a divide???"
My personal view is this is exactly the sort of thing you don't want. None of those things. Just more pins and (maybe) more memory.
Yet those are potential customers who say they need security ?
Easy to say, but that, plus PLL and Crystal Support, are all outside of the P1V verilog files, so you are into Custom Design.
Interestingly I am quite happy to use one of the many cheap clock chips that are available these days, why do you need PLL when you can use these babies for about the same price as a rock!
Yes, you could use something like Si5351A, which is MSOP10 and runs up to 200MHz.
Bumps the system price a little, ~ US$1, but has a frequency precision way above P1 or P2 PLLs.
jmg Yet those are potential customers who say they need security ?
Good point.
As an aside, I lost my job last month when the clinic I work for got shut down. So the receptionist and I decided to start a new one. Two weeks to create a medical practice from scratch. Need to really focus on decisions. Negotiate a 5 year lease in 15 minutes. Trip to Ikea, two trailerloads of furniture, whole family built it all in a weekend. Computer network built in a couple of hours.
And if I was project managing the P1+ memory/pins project, I would say, yes, you can have things like security fuses, but if it takes more than one day to do this, then it doesn't get included.
Security fuses were supposed to be done for the last P2 failed shuttle a few years ago. Now they are being replaced by OTP.
AFAIK PLL is being tested in the P2 frame. But the P1 counters require PLLs.
But P1+ is not a new design like the P2 is. The multiply and divide instructions can most likely be lifted virtually as-is from the P2. If not, then forget it.
Many of us already have extended cog ram and additional hub ram already running. No issues here. Been there, done that.
If we follow the P2 path, then only a tiny ROM will be required to boot, with/without security.
Everything here needs to be verified for the P2. Currently these are the features that are not being proven by the pad frame anyway.
Anyway this thread is probably a total waste of time as I don't think Parallax are interested. So it will probably be the FPGA or ARM route for production.
Anyway this thread is probably a total waste of time as I don't think Parallax are interested. So it will probably be the FPGA or ARM route for production.
Even if they were interested, the time lines would be wrong.
It's not a total waste of time, as you have worked out you can develop with P1, and track FPGAs until Production is needed.
Then, you can choose just enough MCU injection to meet security, or just enough FPGA to enhance specs and meet security.
If you need good integer maths, and comms, there is even the intel D2000 to look at now.
Choices are only expanding
I see the P1B+ replacing the long in the tooth P1 in the long run. But it is not and should not be one of those enhanced P1Vs, that's not what is needed. We need a plain and simple Prop with more memory, more I/O (maybe 56 with 8 internal) and hopefully the same sized package by using QFP64. Yes, security "fuses" will need to be added. The thing is, absolute minimum fuss and features. P2 will be too big and fancy for a the bulk of the Prop requirements but P1 is a bit too basic now as is. Except for a security setting mechanism there should be no change to the Spin ROM, it can still be used the same way P1 is used now as there are other options for taking advantage of the extra memory now.
If though someone identifies a suitable FPGA such as the Lattice parts that will do a full P1+ then great, please let us know because I will also explore that option too.
I think you said you also needed more hub memory and that will require changes to the Spin interpreter I think.
Yeah it was an easy fix which thankfully fit within the instructions available, once I found it (that was the hardest part).
What is the address map in your modified version of the Spin VM? Do you have a hole in the middle of the RAM address space where the ROM is located? How does that work with the Spin compiler? Is it able to understand that hole?
Yeah it was an easy fix which thankfully fit within the instructions available, once I found it (that was the hardest part).
What is the address map in your modified version of the Spin VM? Do you have a hole in the middle of the RAM address space where the ROM is located? How does that work with the Spin compiler? Is it able to understand that hole?
From what I recall (and it has been a long time), ROM was still decoded and working from $8000-$FFFF. I just made it allow proper reads/writes above the 64kB address and prevented the SPIN interpreter shortcut from generating addresses that misused the top 16 of the 32 bits, thereby reading from an incorrect range when foldover is not present. The SPIN interpreter itself still is limited to 32kB code of course. I just enabled access to higher memory in the long[] word[] and byte[] type of instruction and allowed SPIN to still do its normal thing.
1. Code protection
2. More pins
3. Analog
4. More ram
These are the features that would make a successful Propeller 2 - hardly anything else is required from our highest-volume customers. While there are many additional requests for counters, a design which is more suited to C, etc, these four items are the exact formula for a successful P2.
This is something we know from asking them, supporting them and working with them for the past eight years.
Analog would be nice, but these past eight years have been very lean years and still no "harvest". Here's one more item that wasn't on Ken's list that I know should be there:
Comments
If anyone has a Lattice 3.7 flow and P1V file sets for Lattice, they could build to check the LFE5U-12, & LFE5U-25 ?
FPGAs continue to advance.
My personal view is this is exactly the sort of thing you don't want. None of those things. Just more pins and (maybe) more memory.
More pins - should be simple as the P1 software already planned for this with the second register set.
More memory. With the ever decreasing costs of chips and the age of the P1, surely it should be possible to have 64k or 128k for a similar price?
And that is it. Do nothing more. Any extra add-ons can be discussed over in the P2 forum.
And then a technical question for those doing the emulation - are there any instruction changes that are needed to address larger hub ram?
addit - @Cluso, I have been a bit busy lately, just set up a medical practice in the Aldinga shopping centre a few shops up from the newsagency. Means even less time for the prop
Bumps the system price a little, ~ US$1, but has a frequency precision way above P1 or P2 PLLs.
Good point.
As an aside, I lost my job last month when the clinic I work for got shut down. So the receptionist and I decided to start a new one. Two weeks to create a medical practice from scratch. Need to really focus on decisions. Negotiate a 5 year lease in 15 minutes. Trip to Ikea, two trailerloads of furniture, whole family built it all in a weekend. Computer network built in a couple of hours.
And if I was project managing the P1+ memory/pins project, I would say, yes, you can have things like security fuses, but if it takes more than one day to do this, then it doesn't get included.
AFAIK PLL is being tested in the P2 frame. But the P1 counters require PLLs.
But P1+ is not a new design like the P2 is. The multiply and divide instructions can most likely be lifted virtually as-is from the P2. If not, then forget it.
Many of us already have extended cog ram and additional hub ram already running. No issues here. Been there, done that.
If we follow the P2 path, then only a tiny ROM will be required to boot, with/without security.
Everything here needs to be verified for the P2. Currently these are the features that are not being proven by the pad frame anyway.
It's not a total waste of time, as you have worked out you can develop with P1, and track FPGAs until Production is needed.
Then, you can choose just enough MCU injection to meet security, or just enough FPGA to enhance specs and meet security.
If you need good integer maths, and comms, there is even the intel D2000 to look at now.
Choices are only expanding
It only requires two Pasm instructions to be changed.
I'd expect him (Peter) to use Tachyon and not SPIN. ;-)
5. In stock
5. In Stock
and
2. More pins
and/or
4. More ram
A nice addition would be
1. Code Protection
And "cream" would be
3. Analog
Correction "past ten years".
Ken Gracey
MachXO3L-9400/ MachXO3LF-9400 - comes in 9x9mm, or 14x14 BGA package, 9400 LUT, and 54KB of RAM 206 io
No price or Evals up yet, but that seems viable for a number of P1V COGS, and some COG-Saving peripherals.