PTRA and PTRB are both 17 bits. So, even though you can express 32 bits in S, after it gets written into PTRA, it's only 17 bits. I used to have PTRA and PTRB at 32 bits, even though only the 17 bottom bits were used (max hub address of $1FFFF), but it was a critical path that stuck out like a sore thumb, as PTRx addressing has to get resolved in a fraction of a cycle.
OK - thanks for the info
Pins 92..95 don't do anything and read '0'. We could make them read something else, of course. Pins 96..127 are the inter-cog I/O's which also connect to ALL the peripherals, so they are available for all kinds of applications inside the chip.
Interesting... I had thought they were wired just like Pins 96..127.
This also means PORTC (PINC, OUTC & DIRC) top nibble is unused (but they could get remapped to another port).
Maybe useful with SERDES to chain the registers. Or as a special intercog purpose such as stalling the instruction pipe for single-stepping if SETRACE is running.
Re: Complete counter / pin docs. It's my understanding we can't fully field test these due to needing real hardware to get real function. I remember Chip saying those will have to wait for real P2 chips. We've got the DAC's by having the FPGA map that to the resistors on the adapter boards...
Interesting... I had thought they were wired just like Pins 96..127.
This also means PORTC (PINC, OUTC & DIRC) top nibble is unused (but they could get remapped to another port).
Maybe useful with SERDES to chain the registers. Or as a special intercog purpose such as stalling the instruction pipe for single-stepping if SETRACE is running.
About having a signal to single-step cogs: The trace signals are going to appear to other cogs a few cycles after the fact. Single-stepping will not be very meaningful. I think that only observing TRACE output from another cog is meaningful. You could do history logging, time measurements, etc., but single-stepping would be all out-of-sync and it would undermine all real-time interaction that the program was supposed to achieve. I'm open to being convinced, otherwise, though.
Re: Complete counter / pin docs. It's my understanding we can't fully field test these due to needing real hardware to get real function. I remember Chip saying those will have to wait for real P2 chips. We've got the DAC's by having the FPGA map that to the resistors on the adapter boards...
I could write the complete CTR docs now. I just got sidetracked by everything else and because it was seeming very difficult to cover how the pins are called out. Once written, though, it will not be complicated to understand. I'll be back on it before long, I think.
If you would, please. The counters are the P1's hidden jewels. It's amazing what can be accomplished with them! The prospect of what additional functionality the P2's counters hold in store is the principal tantalizing aspect that could get me excited about the P2.
Re: Complete counter / pin docs. It's my understanding we can't fully field test these due to needing real hardware to get real function. I remember Chip saying those will have to wait for real P2 chips. We've got the DAC's by having the FPGA map that to the resistors on the adapter boards...
? DACs and Delta-Sigma cells I can understand, but counters are only Logic, so I would expect those to be fully functional in the FPGA version ?
If you would, please. The counters are the P1's hidden jewels. It's amazing what can be accomplished with them! The prospect of what additional functionality the P2's counters hold in store is the principal tantalizing aspect that could get me excited about the P2.
? DACs and Delta-Sigma cells I can understand, but counters are only Logic, so I would expect those to be fully functional in the FPGA version ?
Yes, they are fully functional. As you pointed out, they are just logic. If I documented those and covered all the instructions, I think the whole chip would be documented. Oh, and I'd need to document the pins, which are not that complicated. Am I dreaming? It seems like there's not much left to do. Spin will build on top of that documentation.
I thought there was interaction between the various pin modes and the counters that we can't see in the FPGA.
See #40.
There may be some small details, like Sigma-Delta Cell feeds into counters, that of course will be hard to emulate with no Sigma-Delta Cell, but the expected new True PWM / Capture / extra channels / Quadrature / etc / etc are all logic.
See #40.
There may be some small details, like Sigma-Delta Cell feeds into counters, that of course will be hard to emulate with no Sigma-Delta Cell, but the expected new True PWM / Capture / extra channels / Quadrature / etc / etc are all logic.
I was looking today at the Altera Cyclone V devices. The biggest one is the A9 and it has 301k LE's for $220.00 from Digi-Key. We could build a board for that that would be good for 8 cogs and Prop III development, too. We could recreate the delta-sigma ADC pin functions by using two adjacent FPGA pins and having one provide negative feedback through a resistor. We'd use the flipflops in the pin circuits to make the turn-around minimal. I'm sure more could be done, as well. We'd probably have to sell that board for upwards of $600. It could enable open Verilog development of Prop III. I suppose we could get all the Verilog worked out for Prop III under MIT license terms. Anyone could use the core, or even make an ASIC, but we would use it in as ASIC with friendly I/O pins.
I've updated to the new FPGA code in my DE2-115 board.
Your BALLS demo looks great!
I'm having trouble getting Video mode 7 (%0111 STR1_RGB9) working.
All I get is a black screen. I have used this mode before in Invaders and some other stuff.
Have I missed something?
I've updated to the new FPGA code in my DE2-115 board.
Your BALLS demo looks great!
I'm having trouble getting Video mode 7 (%0111 STR1_RGB9) working.
All I get is a black screen. I have used this mode before in Invaders and some other stuff.
Have I missed something?
Cheers
Brian
Did you notice that there are three new bits in the VID configuration? What you'll need to do is insert three 0 bits between bits1 and 0 of the value you were using for SETVID.
About having a signal to single-step cogs: The trace signals are going to appear to other cogs a few cycles after the fact. Single-stepping will not be very meaningful. I think that only observing TRACE output from another cog is meaningful. You could do history logging, time measurements, etc., but single-stepping would be all out-of-sync and it would undermine all real-time interaction that the program was supposed to achieve. I'm open to being convinced, otherwise, though.
Chip,
Being able to trace what is happening is fantastic.
I think this would be so much better/usable if there were a way to stall the pipe at stage 4 (probably the easiest way for you) by just ORing another bit into the stall logic if both SETRACE is enabled and STALL is enabled (STALL disabled/enabled by setting via an extra bit in the SETRACE instruction).
Lets presume we have a "STALL" signal (to be decided where it comes from - perhaps a pin, perhaps an internal signal OR'd from all cogs together). A "1" indicates "STALL".
A tracer (slave) cog may sit waiting for an address signal mask (WAITPEQ) to trigger. Once triggered, the slave sets a "STALL" pin/signal ="1" to stall the traced cog. There will be some small delay before this happens ( a few instructions). The tracer cog can then effectively step the traced cog by setting the "STALL" pin/signal ="0" and then immediately back to "1" using 2 sequential 1 clock instructions.
It might not be possible to just allow 1 instruction in the traced cog to execute. Perhaps the traced cog could implement a single clock cycle delay after the STALL signal resets?
Any restrictions, such as real time execution, etc, would be acceptable.
It could enable open Verilog development of Prop III. I suppose we could get all the Verilog worked out for Prop III under MIT license terms. Anyone could use the core, or even make an ASIC, but we would use it in as ASIC with friendly I/O pins.
I just woke up, I'm half asleep, did I read that correctly? There is even serious consideration of open sourcing the Propeller logic design?.
That would surely be a first among purveyors of currently produced processors or MCU's.
Perhaps the first in open community development of a next generation device by a company.
It would certainly put a din't in all the "open hardware" claims of others, Arduino for example.
Did you notice that there are three new bits in the VID configuration? What you'll need to do is insert three 0 bits between bits1 and 0 of the value you were using for SETVID.
Yes Chip, I picked that up in your VGA 800x600 demo.
I also noticed that CFGPINS is not used now in that same demo.
The previous VGA demos used the following
pinmask long %1111
pindacs long %1111_101100000 'pin configuration for video DAC
cfgpins pinmask,pindacs
...Does that reduce Parallax's "crown jewels" or "secret source" down to just the analogue parts of the design?
I figure only Parallax would believe in it enough to build it, as it would look too weird to other companies for them to risk anything on. It would be fine if the greater world ignored it, but it had sufficient application among a limited base.
Does that reduce Parallax's "crown jewels" or "secret source" down to just the analogue parts of the design?
Did anyone tell Ken yet?
Yes, this does need careful commercial consideration.
It could have a place in Education, but I'm not sure anyone will produce runs using using FPGA, at least not at the top end.
It does not make sense, to spend $600, to replace an $18(?) device.
A plus here, is the price of these monster FPGAs, is always coming down.
The trick is to avoid 'simply working for Altera'.
If you step back and think how someone might use a FPGA Prop, I think there is potential for Parallax to ship a P2+FPGA on one board, and either drop one COG into the FPGA, or just use fast interconnects. (to an even cheaper FPGA)
'Standard code' runs in P2, and special code, that cannot run in a P2 COG, runs in the 9th COG on the FPGA, but that COG can have direct, very high speed, access to a blank-sheet of peripherals.
Common SW flows, allow easy hop from one to the other.
One important number in all this, will be how fast can Cyclone V run ?
A good first step, would be to build a core for BeMicro CV.
That gives a handle on the speed of Cyclone V, and that part (5CEFA2F) is cheap enough to place along side a P2 device.
As P III evolves and FPGA prices drop, the next-up device could be used - ideally, you would choose a package early that allowed that. Now you have 8 x P2 COGS and 1 x P3 COG, on the same PCB design.
I certainly would be a taker of a "big FPGA" board, if that buys me the possibility to make custom configurations in which a single or multiple COG's are interfaced to on chip or on board (custom) peripherals.
The IP protection issue could be (partially) solved by distributing encrypted IP modules, the same way the NIOS processor source code is not disclosed. But it still allows to add custom instructions..
Maybe the biggest risc of a (more) shared development effort could be that a P3 design would never be finished given the collective creative ernergy on this forum. Maybe the board would never be finished....... Eeven now ideas for new instructions are abundant.
Enter Chip in a new role as the wise arbitrator that rules firmly over the quarreling children at his feet that all believe in their grand design features.....
Do you see anything on an oscilloscope? Are the sync signals there? The sync signals now can only be generated by literal mode %0000. It used to be that you could have sync signals stored in the long-size pixels from AUX, but it created a lot of headaches trying to get video drivers debugged, so now those bits are handled differently. In fact, it's no longer bits 24 and 25 for sync. It's bit 0. Just look at the docs for the VID section where it talks about sync signalling. Also, see my VGA code examples.
I'm using your latest VGA demo as my base code. It is generating a 800x600 60Hz signal according to my monitor.
It appears to be a perfect black on black picture.
I'm using your latest VGA demo as my base code. It is generating a 800x600 60Hz signal according to my monitor.
It appears to be a perfect black on black picture.
I will investigate this in the morning. I might have broken something.
1) Regarding the verilog, I'd actually suggest GPL in this case. That way, if someone wanted to make an ASIC that was not open, they (theoretically) would have to buy a license from Parallax.
2) Regarding the dev board, I'd suggest making it very usable as a generic Cyclone V development board as well - potentially another revenue source to parallax.
3) Instead of buying from Digikey, approach Altera for discounted parts - after all, it would be a design win, and another dev board, for them
4) map the prop component/vga to on-chip transceivers and provide DVI out along with the analog out
5) bring out 128 I/O's to four 40 pin .1" headers for easy prototyping of external circuitry
6) also... make use of the Arm core on the chip. Add a uSD, external ram (one for the soft core, one for the hard Arm), and run the prop dev software right on the device
I was looking today at the Altera Cyclone V devices. The biggest one is the A9 and it has 301k LE's for $220.00 from Digi-Key. We could build a board for that that would be good for 8 cogs and Prop III development, too. We could recreate the delta-sigma ADC pin functions by using two adjacent FPGA pins and having one provide negative feedback through a resistor. We'd use the flipflops in the pin circuits to make the turn-around minimal. I'm sure more could be done, as well. We'd probably have to sell that board for upwards of $600. It could enable open Verilog development of Prop III. I suppose we could get all the Verilog worked out for Prop III under MIT license terms. Anyone could use the core, or even make an ASIC, but we would use it in as ASIC with friendly I/O pins.
I'm up for a 2-300 dollar board to help with P3. I would likely buy direct / student somehow as I did with the DE2. A standard board is appealing. But, these only exist for a while. Then a new standard board ends up out there. Moving target.
If Parallax produced a board at say, $600. Maybe. I might want to be on the installment plan for that one, LOL. This board would be out there and consistent across the effort. I like that a lot.
The DE2 becomes a learning board when real P2 chips end up out there. I'm OK with that because I got it as such, not paying $600 plus. Some others who did spend for it might think differently, though they are free to sell theirs off too.
Minor league discussion in the longer term, IMHO.
A few thoughts:
Selling chips is a low margin per transaction affair, but it's a non-linear one too. A small number of people can generate a lot of income that way. And value adds are non-linear. Known equation.
Selling services is a much higher margin per transaction affair, but it's linear. A small number of people can generate a lot of income that way too, but it has a much lower peak income per person. Also known, but a bit different model for Parallax.
If selling the chips is put into a market scenario with other sources, Parallax is very highly likely to lose on price, but would still have education / support connected to the product. Red Hat made this work, but they also could get annual contracts out of people too. I would think this would need to happen. Not all users would buy them, nor would they have to. Make them want to. That's a business model with a ton of money behind it, done right. I've many years experience with this.
Annual CPU support contracts of some sort could work for those employing the IP and who need support on it of various kinds. Let's assume we get P1 style releases where it just works. That support would be engineering / software related. Assuming a P3 always in motion then that support would be related to bug fixes / features required / implementation / integration services.
If we all contributed, the IP would be distributed among Parallax and the contributors. Linux is this way. Not a bad thing. There is one layer of protection right there.
There would need to be a discussion on whether or not the IP could be used in FPGA, manufactured in silicon, in whole and in part at a minimum. And the dynamics of those things warrants a long and highly engaging discussion IMHO. What those terms are and how they are structured is very important.
GPL has the advantage of being strong and well understood. Alternative licensing could generate non-linear type revenue, and that's something I see as important to preserving the culture of Parallax as a workplace.
BSD / MIT has similar advantages, but the alternative licensing packs less of a punch. Still there though.
A Parallax open type license would require legal. It would not be recognized nor strong until considerable time and a market vetting has passed it as such. It is alternative licensing.
I really don't know what I think of this overall. The appeal of contributing is a no brainer. Making sure everybody can feed their families and see Parallax and related / dependent people grow as they should is murky at best to me right now.
Comments
This also means PORTC (PINC, OUTC & DIRC) top nibble is unused (but they could get remapped to another port).
Maybe useful with SERDES to chain the registers. Or as a special intercog purpose such as stalling the instruction pipe for single-stepping if SETRACE is running.
About having a signal to single-step cogs: The trace signals are going to appear to other cogs a few cycles after the fact. Single-stepping will not be very meaningful. I think that only observing TRACE output from another cog is meaningful. You could do history logging, time measurements, etc., but single-stepping would be all out-of-sync and it would undermine all real-time interaction that the program was supposed to achieve. I'm open to being convinced, otherwise, though.
I could write the complete CTR docs now. I just got sidetracked by everything else and because it was seeming very difficult to cover how the pins are called out. Once written, though, it will not be complicated to understand. I'll be back on it before long, I think.
Thanks! for the picture. Cool!!!!
Thanks,
-Phil
? DACs and Delta-Sigma cells I can understand, but counters are only Logic, so I would expect those to be fully functional in the FPGA version ?
Ditto..
Yes, they are fully functional. As you pointed out, they are just logic. If I documented those and covered all the instructions, I think the whole chip would be documented. Oh, and I'd need to document the pins, which are not that complicated. Am I dreaming? It seems like there's not much left to do. Spin will build on top of that documentation.
That said, yes! Please do, if it makes sense now.
See #40.
There may be some small details, like Sigma-Delta Cell feeds into counters, that of course will be hard to emulate with no Sigma-Delta Cell, but the expected new True PWM / Capture / extra channels / Quadrature / etc / etc are all logic.
P2_Instructions_20131126.spin
I was looking today at the Altera Cyclone V devices. The biggest one is the A9 and it has 301k LE's for $220.00 from Digi-Key. We could build a board for that that would be good for 8 cogs and Prop III development, too. We could recreate the delta-sigma ADC pin functions by using two adjacent FPGA pins and having one provide negative feedback through a resistor. We'd use the flipflops in the pin circuits to make the turn-around minimal. I'm sure more could be done, as well. We'd probably have to sell that board for upwards of $600. It could enable open Verilog development of Prop III. I suppose we could get all the Verilog worked out for Prop III under MIT license terms. Anyone could use the core, or even make an ASIC, but we would use it in as ASIC with friendly I/O pins.
I've updated to the new FPGA code in my DE2-115 board.
Your BALLS demo looks great!
I'm having trouble getting Video mode 7 (%0111 STR1_RGB9) working.
All I get is a black screen. I have used this mode before in Invaders and some other stuff.
Have I missed something?
Cheers
Brian
Did you notice that there are three new bits in the VID configuration? What you'll need to do is insert three 0 bits between bits1 and 0 of the value you were using for SETVID.
Being able to trace what is happening is fantastic.
I think this would be so much better/usable if there were a way to stall the pipe at stage 4 (probably the easiest way for you) by just ORing another bit into the stall logic if both SETRACE is enabled and STALL is enabled (STALL disabled/enabled by setting via an extra bit in the SETRACE instruction).
Lets presume we have a "STALL" signal (to be decided where it comes from - perhaps a pin, perhaps an internal signal OR'd from all cogs together). A "1" indicates "STALL".
A tracer (slave) cog may sit waiting for an address signal mask (WAITPEQ) to trigger. Once triggered, the slave sets a "STALL" pin/signal ="1" to stall the traced cog. There will be some small delay before this happens ( a few instructions). The tracer cog can then effectively step the traced cog by setting the "STALL" pin/signal ="0" and then immediately back to "1" using 2 sequential 1 clock instructions.
It might not be possible to just allow 1 instruction in the traced cog to execute. Perhaps the traced cog could implement a single clock cycle delay after the STALL signal resets?
Any restrictions, such as real time execution, etc, would be acceptable.
That would surely be a first among purveyors of currently produced processors or MCU's.
Perhaps the first in open community development of a next generation device by a company.
It would certainly put a din't in all the "open hardware" claims of others, Arduino for example.
I notice the Opencores guys use the BSD license http://opencores.org/opencores,faq#whatlicense but I guess there is plenty of time to think about that.
Does that reduce Parallax's "crown jewels" or "secret source" down to just the analogue parts of the design?
Did anyone tell Ken yet?
Yes Chip, I picked that up in your VGA 800x600 demo.
I also noticed that CFGPINS is not used now in that same demo.
The previous VGA demos used the following
Is there a reason for that being removed?
I figure only Parallax would believe in it enough to build it, as it would look too weird to other companies for them to risk anything on. It would be fine if the greater world ignored it, but it had sufficient application among a limited base.
I pulled those out for now, since they don't do anything in the FPGA. When we get the real chip, we'll put them back in.
Did you get that video mode working?
Yes, this does need careful commercial consideration.
It could have a place in Education, but I'm not sure anyone will produce runs using using FPGA, at least not at the top end.
It does not make sense, to spend $600, to replace an $18(?) device.
A plus here, is the price of these monster FPGAs, is always coming down.
The trick is to avoid 'simply working for Altera'.
If you step back and think how someone might use a FPGA Prop, I think there is potential for Parallax to ship a P2+FPGA on one board, and either drop one COG into the FPGA, or just use fast interconnects. (to an even cheaper FPGA)
'Standard code' runs in P2, and special code, that cannot run in a P2 COG, runs in the 9th COG on the FPGA, but that COG can have direct, very high speed, access to a blank-sheet of peripherals.
Common SW flows, allow easy hop from one to the other.
One important number in all this, will be how fast can Cyclone V run ?
A good first step, would be to build a core for BeMicro CV.
That gives a handle on the speed of Cyclone V, and that part (5CEFA2F) is cheap enough to place along side a P2 device.
As P III evolves and FPGA prices drop, the next-up device could be used - ideally, you would choose a package early that allowed that. Now you have 8 x P2 COGS and 1 x P3 COG, on the same PCB design.
I'm still looking into it.
The IP protection issue could be (partially) solved by distributing encrypted IP modules, the same way the NIOS processor source code is not disclosed. But it still allows to add custom instructions..
Maybe the biggest risc of a (more) shared development effort could be that a P3 design would never be finished given the collective creative ernergy on this forum. Maybe the board would never be finished....... Eeven now ideas for new instructions are abundant.
Enter Chip in a new role as the wise arbitrator that rules firmly over the quarreling children at his feet that all believe in their grand design features.....
Do you see anything on an oscilloscope? Are the sync signals there? The sync signals now can only be generated by literal mode %0000. It used to be that you could have sync signals stored in the long-size pixels from AUX, but it created a lot of headaches trying to get video drivers debugged, so now those bits are handled differently. In fact, it's no longer bits 24 and 25 for sync. It's bit 0. Just look at the docs for the VID section where it talks about sync signalling. Also, see my VGA code examples.
It appears to be a perfect black on black picture.
I will investigate this in the morning. I might have broken something.
I'll keep looking into it.
Cheers
Brian
It was a SILLY mistake by me in the end!
Accidently was sending a zero color value...Oops!
Sorry about that.
Thanks
1) Regarding the verilog, I'd actually suggest GPL in this case. That way, if someone wanted to make an ASIC that was not open, they (theoretically) would have to buy a license from Parallax.
2) Regarding the dev board, I'd suggest making it very usable as a generic Cyclone V development board as well - potentially another revenue source to parallax.
3) Instead of buying from Digikey, approach Altera for discounted parts - after all, it would be a design win, and another dev board, for them
4) map the prop component/vga to on-chip transceivers and provide DVI out along with the analog out
5) bring out 128 I/O's to four 40 pin .1" headers for easy prototyping of external circuitry
6) also... make use of the Arm core on the chip. Add a uSD, external ram (one for the soft core, one for the hard Arm), and run the prop dev software right on the device
If Parallax produced a board at say, $600. Maybe. I might want to be on the installment plan for that one, LOL.
The DE2 becomes a learning board when real P2 chips end up out there. I'm OK with that because I got it as such, not paying $600 plus. Some others who did spend for it might think differently, though they are free to sell theirs off too.
Minor league discussion in the longer term, IMHO.
A few thoughts:
Selling chips is a low margin per transaction affair, but it's a non-linear one too. A small number of people can generate a lot of income that way. And value adds are non-linear. Known equation.
Selling services is a much higher margin per transaction affair, but it's linear. A small number of people can generate a lot of income that way too, but it has a much lower peak income per person. Also known, but a bit different model for Parallax.
If selling the chips is put into a market scenario with other sources, Parallax is very highly likely to lose on price, but would still have education / support connected to the product. Red Hat made this work, but they also could get annual contracts out of people too. I would think this would need to happen. Not all users would buy them, nor would they have to. Make them want to. That's a business model with a ton of money behind it, done right. I've many years experience with this.
Annual CPU support contracts of some sort could work for those employing the IP and who need support on it of various kinds. Let's assume we get P1 style releases where it just works. That support would be engineering / software related. Assuming a P3 always in motion then that support would be related to bug fixes / features required / implementation / integration services.
If we all contributed, the IP would be distributed among Parallax and the contributors. Linux is this way. Not a bad thing. There is one layer of protection right there.
There would need to be a discussion on whether or not the IP could be used in FPGA, manufactured in silicon, in whole and in part at a minimum. And the dynamics of those things warrants a long and highly engaging discussion IMHO. What those terms are and how they are structured is very important.
GPL has the advantage of being strong and well understood. Alternative licensing could generate non-linear type revenue, and that's something I see as important to preserving the culture of Parallax as a workplace.
BSD / MIT has similar advantages, but the alternative licensing packs less of a punch. Still there though.
A Parallax open type license would require legal. It would not be recognized nor strong until considerable time and a market vetting has passed it as such. It is alternative licensing.
I really don't know what I think of this overall. The appeal of contributing is a no brainer. Making sure everybody can feed their families and see Parallax and related / dependent people grow as they should is murky at best to me right now.