Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.
The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.
Yep, a Prop123-A9, and the status bit changes look good.
cluso99, your comments are not conducive to getting the P2 as soon as possible. Could you please refrain from proposals that are counter to the P2? Parallax has made a commitment to producing the P2. We should all work together to support the P2 development.
Just because you disagree with my comments doesn't in any way mean they are wrong, or against Parallax's interest. In fact, my comments are entirely, in my perceived way, made for the benefit of Parallax, and probably against my own desires too.
But reality must be examined. Parallax revenue is at stake here. The current P2 cannot possibly generate revenue for Parallax as quickly as a P1 variant, due to the additional requirements of P2, including silicon, software and documentation issues.
However, this does not change my view that a Bigger P1 is now, more than ever, the immediate requirement! Now I see you can use the P2 ring soup with the P1 extras.
....
At least a "Big P1" would bring us backward compatibility, such that all the P1 software, objects, demos and tools could be used from day one of silicon. P2 has now moved too far away from P1 compatibility that it must be considered a new beast, not an upgraded P1.
- but your P1x totally fails to deliver "bring us backward compatibility" !!
It lacks the same Crystal/RC Oscs & config, lacks the same PLL design, and lacks any Video PLL - all that claim of "software used from day one" is a mirage.
It also is now in a much larger package, with two Vcc's, so it seems the earlier 32io did not last very long at all !
All of this means 'your P1x' also "must be considered a new beast, not an upgraded P1"
The Verilog is testable, and needs to be tested, in FPGA, exactly the same for P1x and P2, and then synthesized.
Reality: P2 is more tested than P1x, so actually represents the lower risk, not to mention a far larger TAM.
Chip,
Glad to see you are still moving forward with things. I for one am looking forward to the P2 as my go to chip for my various robotic projects, as well as experimenting with it in the areas of sound generation.
I really think that it's going to be a fun beast to work with and program, and I am sure that I am not alone in this.
Let's not not diverge into alternate paths or what could have been's, and just get what we have finalized into a chip we can all start using soon.
Chip,
Could the P1 instruction set be easily inserted into the P2?
While there probably would be some extras required, this surely may mitigate bugs, and would permit the use of existing software with minimal changes, if any.
Could the P1 instruction set be easily inserted into the P2?
What does that even mean ? They are different CPUs.
Did you meant to ask can a synthesised P1 be 'dropped inside' the P2 ring ?
Why not ask if a RISV-V can be 'dropped inside' a P2 ring ?
What happens to all the analog features, currently designed into the P2 ring, but NOT in any P1 design ?
While there probably would be some extras required, this surely may mitigate bugs, and would permit the use of existing software with minimal changes, if any.
Why the claim "surely may mitigate bugs" ? - ALL Verilog code needs to be fully tested. Reality: There is no proven P1 Verilog Silicon.
P1x and P2 really have exactly the same Verilog-> FPGA testing issues, but P2 has a significant head start...
Unless you clone ALL the P1 Analog sections precisely, which is NOT done in the P2 Ring, you cannot simply reuse existing binaries.
Even classic P1 ADC circuits, rely on buffer thresholds, and are unlikely to operate the same in 180nm.
I guess that can be checked on the new P2 PAD Ring test silicon
Once you add 'minimal changes', you now need two code bases...
Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.
The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.
Yep, a Prop123-A9, and the status bit changes look good.
Thanks, Chip, and remember to take it easy!
Affirmative on the Prop123-A9.
Garryj,
Here is an 80MHz setup for the Prop123-A9 board. It has 8 cogs and all 64 smart pins:
These days you simulate the RTL of the chip, and simulate a gate level extraction with loading before tapeout. I assume tree house will do this, though Parallax would be responsible for the stimulus, and free house would give a coverage figure. Most main line chip vendors include scan chains for production test.
Chip, do you have someone (several someones, preferably) you trust to review your verilog? You really should have a peer review of your code.
When we go to synthesis, it gets linted really well. That's it.
I don't think there are any obvious bugs someone would find looking at the Verilog. It's more modal stuff in peripherals where hard-to-discover things lurk, and they only come out when running the FPGA. That's what I'm mainly worried about.
These days you simulate the RTL of the chip, and simulate a gate level extraction with loading before tapeout. I assume tree house will do this, though Parallax would be responsible for the stimulus, and free house would give a coverage figure. Most main line chip vendors include scan chains for production test.
This chip has a TESn pin to put it into scan mode. I wanted all the logic verifiable, this time around. The analog pads will still need to be tested, outside of the scan chain.
potatohead,
It's like 16 DSPs with 64 DACs or ADCs or some combo of each adding up to 64. All kinds of nifty and weird things can be done with audio in this thing.
I need to work up a board that will take a pile of pins being used as DACs and mix them into a stereo output.
In my understanding a P1+ is already doable with various FPGA variations. And the price is coming down quite fast. Even if Parallax could sell a P1+ for say $10 it will be less then 2 years and a P1+ FPGA is cheaper then a P1+ Chip from Parallax.
The whole "We need a P1+" train left the station around 5 years ago, together with a lot of people, I certainly miss @pullmoll, for example, or @mpark, or...
Now it is definitive to late for a P1+. Sorry @clusso99, but this is not just a financial risk like the P2 but a preprogrammed financial disaster. Even $250-$350 as a ballpark, and then a production run. How can they ever get that money back, since FPGA prices are falling and the IP/Verilog is out in the public?
The P2 is - as usual - almost there, but this time I have the strong feeling that @Ken AND @Chip agree on the same timeline.
Overall Parallax has spend some maybe 2-3 million over the last 10 years, investing into the next generation of the propeller. Now they have to, and will, bite the apple and get it in production.
Everything else would be simply stupid, if not insane.
And for sure has @Chip a hard time to let it got, and needs reassurance from us that it is OK now and he can say DONE!
It is completely wrong now to say, look - you have a new product, but better not produce it because you need to write DOCUMENTATION, and everybody hates that.
PropGCC is not ready yet, but there is already a working C compiler. It even can compile old SPIN for the P2. As far as I was able to follow the PropGCC posts, getting it basically running is not that far away.
SPIN2 will be ready before we really get silicon, and I am quite sure the changes for the PropTool to adjust to P2 Syntax are not so hard.
And then there is SPIN-WRAP a somehow unnoticed gem, allowing to use P1-SPIN unchanged in C by running a SPIN-Interpreter. That could work for the P2 too, and I even think some one could write a PASM1-emulator for the P2. Even if I need to state clearly to @heater, that this is impossible and remind him that he does not want to write any emulator ever again.
Someone will.
And @Ken made a really good decision with the whole Blockly endeavor. It took me a while to understand that move. Just brilliant, business-wise. And now it will pay out double, because as soon as PropGCC works for the P2 its just the simple library.
And all 10 things you listed as to be needed to be done for a P2, would also be needed for a P1+, or do I miss something here?
Must agree with Mike here. It's way too late for any P1+ ideas now. Focus on P2. It looks like we're finally getting there. If it works, or mainly works, it will be good. No distractions, please.
I just tried. The FPGA image loads fine, and PNut_v21_80MHz compiles and loads the code fine, but the cogs don't get started.
Is default startup sysclock set to 80MHz? I tried with no CLKSET and a CLKSET #$ff.
Edit: Loaded the all_cogs_blink program and no joy there, either.
Edit2: It does run the all_cogs_blink program, but you need to repeat F11'ing, and after a random number of attempts, the program runs. No success so far with my much larger program. The 120MHz v21 works, but my USB demo still doesn't.
I just tried. The FPGA image loads fine, and PNut_v21_80MHz compiles and loads the code fine, but the cogs don't get started.
Is default startup sysclock set to 80MHz? I tried with no CLKSET and a CLKSET #$ff.
Edit: Loaded the all_cogs_blink program and no joy there, either.
Edit2: It does run the all_cogs_blink program, but you need to repeat F11'ing, and after a random number of attempts, the program runs. No success so far with my much larger program. The 120MHz v21 works, but my USB demo still doesn't.
I can wait for the upcoming 80MHz drop.
Garry, sorry about this. I think the problem is that I didn't adjust the NCO constant for the 20MHz "RC" mode.
I added a new mode to the smart pin measurements, where you can do a timeout counter on A-high/rise/edge.
WRPIN - use to set mode %10010
WXPIN - sets timeout period in clocks
WYPIN - %11x = edge, %101 = rise, %100 = high (other mode %0xx = time X A-highs/rises/edges)
If the A-edge/rise/high does not occur in X clocks, INA is raised and the timeout counter starts over. Each time the edge/rise/high does occur, the timer is reset. Only when it runs out do you get an event.
RDPIN can always be used to get the current elapsed time, since the start, or the last edge/rise/high. That timer tops out at $8000_0000.
So, this keeps firing on each full timeout period when the edge/rise/high never happens. And you can always poll RDPIN to find the total elapsed time since the last edge/rise/high.
I will document this and get it into the next release.
All the building blocks were in place to add this, at the cost of a few gates per smart pin. I had been thinking about something like this for a while, because it's always an odd thing to program for watchdog-type timeout - especially when events may be very fast. This is useful for knowing if some periodic signal drops below a certain frequency or a state goes away.
I improved the Goertzel stuff in the streamer by getting rid of GETXCOS and GETXSIN, which fetch different accumulations at inescapably different times, and making one new instruction 'GETXACC D' which gets the cosine accumulator into D and the sine accumulator into the next instruction's S, giving you a proper snapshot of the accumulators. Both accumulators get grabbed on the same clock. This should improve the Goertzel performance slightly, getting rid of niggling two-clock differences between accumulations. And, of course, GETXACC is protected from interruption, so that the next instruction always executes with the other accumulator in its S.
... making one new instruction 'GETXACC D' which gets the cosine accumulator into D and the sine accumulator into the next instruction's S, giving you a proper snapshot of the accumulators.
Chip,
Is that an immediate at the S port of the ALU or an S field (operand) of the instruction decode?
... making one new instruction 'GETXACC D' which gets the cosine accumulator into D and the sine accumulator into the next instruction's S, giving you a proper snapshot of the accumulators.
Chip,
Is that an immediate at the S port of the ALU or an S field (operand) of the instruction decode?
It doesn't matter if the next instruction calls for a register or an immediate, the sine accumulator becomes the 32-bit S value for the next instruction, regardless. So, it would be the "S port of the ALU", not the 9-bit S field within the instruction.
I saw your comment about the smart pins. Were you able to get a better explanation of how the pins work.
I am confused. Attempting to set counter modes like in the P1.
Thanks
I saw your comment about the smart pins. Were you able to get a better explanation of how the pins work.
I am confused. Attempting to set counter modes like in the P1.
Thanks
Been too long... if I did, I've completely forgotten. I haven't touched P2 anything in ages.
I saw your comment about the smart pins. Were you able to get a better explanation of how the pins work.
I am confused. Attempting to set counter modes like in the P1.
Thanks
Read the P2 docs on smartpins - you will see the configuration modes that were in the P1 counters, plus extras
Pilot,
Do you have some particular count mode in mind?
Having just used a counter on the Prop1, to generate a 1 MHz clock, I can say the counters there immediately felt different simply because of the way to set them up. On the Prop2 there is an instruction, WRPIN, to do the job. Whereas on the Prop1, counter config is done with cog registers, namely CTRA/CTRB.
On the Prop1 it is two counters per Cog. On the Prop2 it is one counter per I/O pin, or more accurately one Smartpin per I/O pin.
Comments
But reality must be examined. Parallax revenue is at stake here. The current P2 cannot possibly generate revenue for Parallax as quickly as a P1 variant, due to the additional requirements of P2, including silicon, software and documentation issues.
Very easy to claim anything, but that's not what your path actually delivers.
The devil is in the details.
- but your P1x totally fails to deliver "bring us backward compatibility" !!
It lacks the same Crystal/RC Oscs & config, lacks the same PLL design, and lacks any Video PLL - all that claim of "software used from day one" is a mirage.
It also is now in a much larger package, with two Vcc's, so it seems the earlier 32io did not last very long at all !
All of this means 'your P1x' also "must be considered a new beast, not an upgraded P1"
The Verilog is testable, and needs to be tested, in FPGA, exactly the same for P1x and P2, and then synthesized.
Reality: P2 is more tested than P1x, so actually represents the lower risk, not to mention a far larger TAM.
Glad to see you are still moving forward with things. I for one am looking forward to the P2 as my go to chip for my various robotic projects, as well as experimenting with it in the areas of sound generation.
I really think that it's going to be a fun beast to work with and program, and I am sure that I am not alone in this.
Let's not not diverge into alternate paths or what could have been's, and just get what we have finalized into a chip we can all start using soon.
Could the P1 instruction set be easily inserted into the P2?
While there probably would be some extras required, this surely may mitigate bugs, and would permit the use of existing software with minimal changes, if any.
Did you meant to ask can a synthesised P1 be 'dropped inside' the P2 ring ?
Why not ask if a RISV-V can be 'dropped inside' a P2 ring ?
What happens to all the analog features, currently designed into the P2 ring, but NOT in any P1 design ?
Why the claim "surely may mitigate bugs" ? - ALL Verilog code needs to be fully tested. Reality: There is no proven P1 Verilog Silicon.
P1x and P2 really have exactly the same Verilog-> FPGA testing issues, but P2 has a significant head start...
Unless you clone ALL the P1 Analog sections precisely, which is NOT done in the P2 Ring, you cannot simply reuse existing binaries.
Even classic P1 ADC circuits, rely on buffer thresholds, and are unlikely to operate the same in 180nm.
I guess that can be checked on the new P2 PAD Ring test silicon
Once you add 'minimal changes', you now need two code bases...
Garryj,
Here is an 80MHz setup for the Prop123-A9 board. It has 8 cogs and all 64 smart pins:
https://drive.google.com/file/d/0B9NbgkdrupkHYy1yYW15WXktS28/view?usp=sharing
When we go to synthesis, it gets linted really well. That's it.
I don't think there are any obvious bugs someone would find looking at the Verilog. It's more modal stuff in peripherals where hard-to-discover things lurk, and they only come out when running the FPGA. That's what I'm mainly worried about.
This chip has a TESn pin to put it into scan mode. I wanted all the logic verifiable, this time around. The analog pads will still need to be tested, outside of the scan chain.
It's like 16 DSPs with 64 DACs or ADCs or some combo of each adding up to 64. All kinds of nifty and weird things can be done with audio in this thing.
I need to work up a board that will take a pile of pins being used as DACs and mix them into a stereo output.
The whole "We need a P1+" train left the station around 5 years ago, together with a lot of people, I certainly miss @pullmoll, for example, or @mpark, or...
Now it is definitive to late for a P1+. Sorry @clusso99, but this is not just a financial risk like the P2 but a preprogrammed financial disaster. Even $250-$350 as a ballpark, and then a production run. How can they ever get that money back, since FPGA prices are falling and the IP/Verilog is out in the public?
The P2 is - as usual - almost there, but this time I have the strong feeling that @Ken AND @Chip agree on the same timeline.
Overall Parallax has spend some maybe 2-3 million over the last 10 years, investing into the next generation of the propeller. Now they have to, and will, bite the apple and get it in production.
Everything else would be simply stupid, if not insane.
And for sure has @Chip a hard time to let it got, and needs reassurance from us that it is OK now and he can say DONE!
It is completely wrong now to say, look - you have a new product, but better not produce it because you need to write DOCUMENTATION, and everybody hates that.
PropGCC is not ready yet, but there is already a working C compiler. It even can compile old SPIN for the P2. As far as I was able to follow the PropGCC posts, getting it basically running is not that far away.
SPIN2 will be ready before we really get silicon, and I am quite sure the changes for the PropTool to adjust to P2 Syntax are not so hard.
And then there is SPIN-WRAP a somehow unnoticed gem, allowing to use P1-SPIN unchanged in C by running a SPIN-Interpreter. That could work for the P2 too, and I even think some one could write a PASM1-emulator for the P2. Even if I need to state clearly to @heater, that this is impossible and remind him that he does not want to write any emulator ever again.
Someone will.
And @Ken made a really good decision with the whole Blockly endeavor. It took me a while to understand that move. Just brilliant, business-wise. And now it will pay out double, because as soon as PropGCC works for the P2 its just the simple library.
And all 10 things you listed as to be needed to be done for a P2, would also be needed for a P1+, or do I miss something here?
Enjoy!
Mike
Any word on how that 80MHz FPGA image worked with your USB code?
Is default startup sysclock set to 80MHz? I tried with no CLKSET and a CLKSET #$ff.
Edit: Loaded the all_cogs_blink program and no joy there, either.
Edit2: It does run the all_cogs_blink program, but you need to repeat F11'ing, and after a random number of attempts, the program runs. No success so far with my much larger program. The 120MHz v21 works, but my USB demo still doesn't.
I can wait for the upcoming 80MHz drop.
Garry, sorry about this. I think the problem is that I didn't adjust the NCO constant for the 20MHz "RC" mode.
New stuff is compiling now.
Thanks.
WRPIN - use to set mode %10010
WXPIN - sets timeout period in clocks
WYPIN - %11x = edge, %101 = rise, %100 = high (other mode %0xx = time X A-highs/rises/edges)
If the A-edge/rise/high does not occur in X clocks, INA is raised and the timeout counter starts over. Each time the edge/rise/high does occur, the timer is reset. Only when it runs out do you get an event.
RDPIN can always be used to get the current elapsed time, since the start, or the last edge/rise/high. That timer tops out at $8000_0000.
So, this keeps firing on each full timeout period when the edge/rise/high never happens. And you can always poll RDPIN to find the total elapsed time since the last edge/rise/high.
I will document this and get it into the next release.
All the building blocks were in place to add this, at the cost of a few gates per smart pin. I had been thinking about something like this for a while, because it's always an odd thing to program for watchdog-type timeout - especially when events may be very fast. This is useful for knowing if some periodic signal drops below a certain frequency or a state goes away.
Is that an immediate at the S port of the ALU or an S field (operand) of the instruction decode?
It doesn't matter if the next instruction calls for a register or an immediate, the sine accumulator becomes the 32-bit S value for the next instruction, regardless. So, it would be the "S port of the ALU", not the 9-bit S field within the instruction.
I saw your comment about the smart pins. Were you able to get a better explanation of how the pins work.
I am confused. Attempting to set counter modes like in the P1.
Thanks
Been too long... if I did, I've completely forgotten. I haven't touched P2 anything in ages.
Read the P2 docs on smartpins - you will see the configuration modes that were in the P1 counters, plus extras
Do you have some particular count mode in mind?
Having just used a counter on the Prop1, to generate a 1 MHz clock, I can say the counters there immediately felt different simply because of the way to set them up. On the Prop2 there is an instruction, WRPIN, to do the job. Whereas on the Prop1, counter config is done with cog registers, namely CTRA/CTRB.
On the Prop1 it is two counters per Cog. On the Prop2 it is one counter per I/O pin, or more accurately one Smartpin per I/O pin.
I am attempting to start with ctra, phsa. Wanting to port this code over from P1.
Looking for a simple start with wrpin, wxpin and wypin example to start any of the modes.
Thanks