Ken, I had actually texted to Wendy at On Semi this morning not to worry about changing course. Where we are headed is pretty certain and changes mean more bumps in our path.
What we will have will be quite a capable chip and should whet people's appetites for something bigger. And some will want something smaller. 8 cogs and 512KB is enough to build nice systems with. By the time we make a 16-cog 1MB version, there will be some good anticipation for it.
If we developed LVDS signalling, where we could transceive packets at 500Mbps, we could virtually expand a base-level chip by giving it access to other identical chips' resources. Then, you just hook up as many chips as you want. The comms would be fast enough to make everything seem like one chip. Something for the future.
If we developed LVDS signalling, where we could transceive packets at 500Mbps, we could virtually expand a base-level chip by giving it access to other identical chips' resources. Then, you just hook up as many chips as you want. The comms would be fast enough to make everything seem like one chip. Something for the future.
Wasn't the Transputer doing fast chip interlinks (as in as fast as process allowed them to) ?
Certainly you could do a HyperBUS/OctaSPI interface that was both master and slave, I see parts coming out with more than one of these buses already.
Something that people don't seem to realize is that many things that required extra cogs on the P1 can be done using Smart Pins or could run within the same cog using interrupts. Most of the applications on the P1 used the extra cogs for I/O drivers. Even when a P1 cog was used as a co-processor, such as for floating point, the main cog would wait for results from the secondary cog. I can't think of many application where true parallel processing was done on the P1.
An 8-cog/512KB P2 will be amazing. More RAM would be nice for graphics, but it will be so nice not to be limited to 32K like on the P1.
Someone explained to me how LVDS works. Its genius is in it's simplicity:
To output, a parallel register is used to bias maybe every fourth differential inverter in a chain. After biasing, the chain is allowed to propagate in series at some analog speed. The final output pair in the inverter chain go over external wires.
To receive, incoming differential data travels through a chain of differential inverters. At some point, the data from maybe every fourth inverter is registered in parallel.
So, there's no bit clock, only a word clock! There are analog bias voltages that must be tuned to control the differential inverter speeds in the transmitter and receiver circuits. Aside from how, exactly, these circuits are realized, that's about all there is to it. Beautifully simple.
Someone explained to me how LVDS works. Its genius is in it's simplicity:
To output, a parallel register is used to bias maybe every fourth differential inverter in a chain. After biasing, the chain is allowed to propagate in series at some analog speed. The final output pair in the inverter chain go over external wires.
To receive, incoming differential data travels through a chain of differential inverters. At some point, the data from maybe every fourth inverter is registered in parallel.
So, there's no bit clock, only a word clock! There are analog bias voltages that must be tuned to control the differential inverter speeds in the transmitter and receiver circuits. Aside from how, exactly, these circuits are realized, that's about all there is to it. Beautifully simple.
Sounds like the secret sauce is in those Analog levels, to set the 'traveling wave' speeds.
Did OnSemi mention what process is required to start to support LVDS ? Seems to be in their ONC18: 0.18 µm CMOS Standard Cell process ?
...
We need to talk about things we can change, efforts we can influence to make the P2 a success.
For example, we don't have the resources to do all the software/documentation and examples like we did for the P1. We will need to establish an open location for creating this documentation, whether a Wiki/GitHub or Google doc (I'm not certain what's the best platform). Do we have much interest in collaborating on a crowd-sourced effort in this way?
In case it wasn't clear, I want the thing done above all else. It's an awesome design. And it's gonna do way more than we think it will just like P1 did.
As for crowd source, yes! I would say to just use github but it's markup isn't quite where it needs to be, though it will work for a lot.
Wikispaces is actually pretty awesome. I would gladly participate, as would most of us. If we do that, Parallax needs to buy an account. I had to smooth talk them into an export when the free option went away, and got limited. I worry about the long term.
We don't want that mess again.
If we break things into chunks, Google docs can work, and we can work together on docs. Even concurrently.
It won't have the uniform look, but so what?
That spit n polish can always be done by most anyone capable.
Best to use a tool that is as friction free for content create as possible.
To me, that is Google docs. We have good starts there anyway.
Whatever gets chosen, I'll do my part on whatever it is.
Happy to help. This has been a big investment and we are all in the know. If we don't do it, it won't get done.
But as you got me here I have to comment on potatohead's statement: "I would say to just use github but it's markup isn't quite where it needs to be, though it will work for a lot."
Yes, keep it in github. Where Parallax already has a lot of stuff.
Github's markup is simple and limited. That is the beauty of it. So easy to use compared to LaTex on the one hand, MS Word on the other, or Google docs in the middle. I don't think I have voluntarily, spontaneously, documented so many things without the frictionless nature of markdown.
Making it quick and easy is important if you want people to contribute.
Whatever one does, it requires somebody at Parallax to have the time to curate it all.
It won't have the uniform look, but so what? That spit n polish can always be done by most anyone capable.
That pretty much boils down to Jen and Stephanie. But geez, that's a lot to add to their already full plates, methinks.
I am a little concerned about the dearth of internal resources available for the all-important documentation job. So many of the past jobs that relied on external contractors/volunteers and crowd-sourcing have fallen a bit short of their objectives -- mostly due to arising and more pressing commitments. I do understand Ken's concerns, but after the big bucks that have been invested in P2 development, a bit more committed to documentation seems like the tip of the iceberg by comparison.
Reminds me of the graffiti in the loo of my dorm in my university:
"Sociology degrees. Please take one"
This kind of documentation is hard. As we probably all know. Somebody has to extract the definitive meaning of everything from the creator, Chip, and translate and present is as something normal humans will understand and can make use of.
Which probably involves introductory explanation of why and how things are as they are.
Reminds me of the graffiti in the loo of my dorm in my university:
"Sociology degrees. Please take one"
This kind of documentation is hard. As we probably all know. Somebody has to extract the definitive meaning of everything from the creator, Chip, and translate and present is as something normal humans will understand and can make use of.
Which probably involves introductory explanation of why and how things are as they are.
I have not met many guys who can do that well.
Well, I thought I was already achieving that with the Google Docs. We just need lots more examples.
Well, pfffff.... I thought I was already achieving that with the Google Docs. We just need lots more examples.
Certainly examples are very good, especially around Smart Pins.
I also like a quasi-netlist approach to make it clear exactly what drives CLOCK,RESET,LOAD,CAPTURE etc in each mode.
Peter had some interesting forth line examples around smart pins. **
I guess the example needs to be 4? way, and copy/paste-able.
* Forth (one liners ?)
* Assembler
* Spin 2
* C
Now I am testing the transition mode and decided to break that up into three words, TRANS to set the mode, PW to set the pulse width (just cycles at present but nanoseconds probably in the manner 100 ns PW ), and PULSES which triggers the number of pulse transitions.
The pulse/cycle mode actually counts out pulses so manually typing $48 WRPIN $8.000C WXPIN 4 WYPIN causes four 50ns pulses in a 150ns period (sweet!) and then typing 2 WYPIN outputs two of those pulses so obviously I will find a way to express that in an easier to use format.
There are tricks to getting those "beyond process" speeds, and in fact you and I have talked about it in depth. When I was at National Semiconductor we were achieving speeds of up to 2 Gigs without any problem using a 350nm process. So I'm not surprised when I hear +5Gigs at 180nm, in fact the technique can be scaled to go even faster.
Comments
What we will have will be quite a capable chip and should whet people's appetites for something bigger. And some will want something smaller. 8 cogs and 512KB is enough to build nice systems with. By the time we make a 16-cog 1MB version, there will be some good anticipation for it.
If we developed LVDS signalling, where we could transceive packets at 500Mbps, we could virtually expand a base-level chip by giving it access to other identical chips' resources. Then, you just hook up as many chips as you want. The comms would be fast enough to make everything seem like one chip. Something for the future.
Wasn't the Transputer doing fast chip interlinks (as in as fast as process allowed them to) ?
Certainly you could do a HyperBUS/OctaSPI interface that was both master and slave, I see parts coming out with more than one of these buses already.
An 8-cog/512KB P2 will be amazing. More RAM would be nice for graphics, but it will be so nice not to be limited to 32K like on the P1.
To output, a parallel register is used to bias maybe every fourth differential inverter in a chain. After biasing, the chain is allowed to propagate in series at some analog speed. The final output pair in the inverter chain go over external wires.
To receive, incoming differential data travels through a chain of differential inverters. At some point, the data from maybe every fourth inverter is registered in parallel.
So, there's no bit clock, only a word clock! There are analog bias voltages that must be tuned to control the differential inverter speeds in the transmitter and receiver circuits. Aside from how, exactly, these circuits are realized, that's about all there is to it. Beautifully simple.
Did OnSemi mention what process is required to start to support LVDS ? Seems to be in their ONC18: 0.18 µm CMOS Standard Cell process ?
There was 'http://propeller.wikispaces.com/'. That was great. How/were could we start a new wiki ?
I'm not sure High Gbps is needed, but one desirable speed point is HS-USB, and that uses 480mbps ~LVDS
https://indico.cern.ch/event/608587/contributions/2614596/contribution.pdf
@Ken: You should not apologize.
In case it wasn't clear, I want the thing done above all else. It's an awesome design. And it's gonna do way more than we think it will just like P1 did.
As for crowd source, yes! I would say to just use github but it's markup isn't quite where it needs to be, though it will work for a lot.
Wikispaces is actually pretty awesome. I would gladly participate, as would most of us. If we do that, Parallax needs to buy an account. I had to smooth talk them into an export when the free option went away, and got limited. I worry about the long term.
We don't want that mess again.
If we break things into chunks, Google docs can work, and we can work together on docs. Even concurrently.
It won't have the uniform look, but so what?
That spit n polish can always be done by most anyone capable.
Best to use a tool that is as friction free for content create as possible.
To me, that is Google docs. We have good starts there anyway.
Whatever gets chosen, I'll do my part on whatever it is.
Happy to help. This has been a big investment and we are all in the know. If we don't do it, it won't get done.
I was wondering what ideas were left over, that could be baked into P3.
I am getting super excited. We may have test chips to document and produce library code on this year!
About the Wiki thing...whatever Heater says:)
a nice sticky FAQ thread will also help.
But as you got me here I have to comment on potatohead's statement: "I would say to just use github but it's markup isn't quite where it needs to be, though it will work for a lot."
Yes, keep it in github. Where Parallax already has a lot of stuff.
Github's markup is simple and limited. That is the beauty of it. So easy to use compared to LaTex on the one hand, MS Word on the other, or Google docs in the middle. I don't think I have voluntarily, spontaneously, documented so many things without the frictionless nature of markdown.
Making it quick and easy is important if you want people to contribute.
Whatever one does, it requires somebody at Parallax to have the time to curate it all.
I am a little concerned about the dearth of internal resources available for the all-important documentation job. So many of the past jobs that relied on external contractors/volunteers and crowd-sourcing have fallen a bit short of their objectives -- mostly due to arising and more pressing commitments. I do understand Ken's concerns, but after the big bucks that have been invested in P2 development, a bit more committed to documentation seems like the tip of the iceberg by comparison.
-Phil
"Sociology degrees. Please take one"
This kind of documentation is hard. As we probably all know. Somebody has to extract the definitive meaning of everything from the creator, Chip, and translate and present is as something normal humans will understand and can make use of.
Which probably involves introductory explanation of why and how things are as they are.
I have not met many guys who can do that well.
Well, I thought I was already achieving that with the Google Docs. We just need lots more examples.
Provide a template of what is required (in small pieces) then let the community fill it in.
Once done, have professional editors edit it.
Anything less will result in pure chaos.
J
It's amazing they achieved such speed in a CMOS 180nm process. 5Gb/s is all you would need. That would go all the way to 4K 60Hz HDMI.
Hi Chip
You don't need to reinvent the wheel!
Onsemi ONC-18 does yet has LVDS, in its standard cell library.
They had developed an image sensor at their facilities in Belgium, for space applications, under 180nm design rules. LVDS signaling!
Many of the documents listed as having references to both OnSemi and LVDS are also related to Fairchild, acquired by OnSemi in 2016.
https://fairchildsemi.com/application-notes/AN/AN-5017.pdf
imagesensors.org/Past%20Workshops/2017%20Workshop/2017%20Papers/P12_innocent_2.pdf
onsemi.com/PowerSolutions/content.do?id=16626
I'm yet to find any reference for comms speed!
Certainly examples are very good, especially around Smart Pins.
I also like a quasi-netlist approach to make it clear exactly what drives CLOCK,RESET,LOAD,CAPTURE etc in each mode.
Peter had some interesting forth line examples around smart pins. **
I guess the example needs to be 4? way, and copy/paste-able.
* Forth (one liners ?)
* Assembler
* Spin 2
* C
**
It's almost good enough. Maybe today it is. Can I drop an image into markup text yet?
@Phil: If we have the material produced, it is there to draw from. Education always needs serious production. Nothing changes there.
For everyone else, there isn't anywhere near the work IMHO.
And to heaters point, simple is better. Github may well be there now. I've not looked in about a year.
Seconded. And the smaller, simpler, leaner that template is, the better.
For example this quick knockup I made a long while ago:
https://bitbucket.org/zicog/pigpio2html
But, you know, Google docs.
Better to have control of your own stuff.
There are tricks to getting those "beyond process" speeds, and in fact you and I have talked about it in depth. When I was at National Semiconductor we were achieving speeds of up to 2 Gigs without any problem using a 350nm process. So I'm not surprised when I hear +5Gigs at 180nm, in fact the technique can be scaled to go even faster.