Demands on Chip after August + and some possible design goals
Ken Gracey
Posts: 7,392
Hey everybody,
Chip has been very productive porting the P1 from Altera to Verilog in the last couple of weeks. Then we took him to DEFCON 22 and he got really inspired by like-minded people. This week he's certainly going to be helping all of us get underway with the Verilog code.
If you've got questions, this would be the week to get them answered. Of course, you may not know what kind of help you need until you have hardware in your hands.
Chip will stay here and help us as much as possible, no matter what, but I would like to make certain the P1 Verilog support doesn't become his new responsibility.
Next week or the week after, I'm thinking he's going to return to Propeller 2 design. While I don't pretend to manage Chip I shall try to give him a productive environment where he can focus on finishing up Propeller 2. Please don't mistake my request for some sort of "silencing the masses" or "free speech" threat. Your questions are fine, anytime, but if you think you can ask them sooner or later, sooner is better.
Once you're into the Verilog and feeling productive, my suggestion is that we work with the focus on some improvements that keep compatibility with the toolchain. Improvements like:
Your involvement Parallax could produce the first fully open, community-designed multicore. Those not familiar with Parallax might cite us as simply trying to get others to do "our" work. But this isn't simply our work anymore, its OUR work [all of us!]. There are ways to facilitate such a project so that everybody benefits. If it turns out we have that role we shall do our best.
Ken Gracey
Chip has been very productive porting the P1 from Altera to Verilog in the last couple of weeks. Then we took him to DEFCON 22 and he got really inspired by like-minded people. This week he's certainly going to be helping all of us get underway with the Verilog code.
If you've got questions, this would be the week to get them answered. Of course, you may not know what kind of help you need until you have hardware in your hands.
Chip will stay here and help us as much as possible, no matter what, but I would like to make certain the P1 Verilog support doesn't become his new responsibility.
Next week or the week after, I'm thinking he's going to return to Propeller 2 design. While I don't pretend to manage Chip I shall try to give him a productive environment where he can focus on finishing up Propeller 2. Please don't mistake my request for some sort of "silencing the masses" or "free speech" threat. Your questions are fine, anytime, but if you think you can ask them sooner or later, sooner is better.
Once you're into the Verilog and feeling productive, my suggestion is that we work with the focus on some improvements that keep compatibility with the toolchain. Improvements like:
- multiply function
- port B 64 I/O pins
- higher speed
- analog input
Your involvement Parallax could produce the first fully open, community-designed multicore. Those not familiar with Parallax might cite us as simply trying to get others to do "our" work. But this isn't simply our work anymore, its OUR work [all of us!]. There are ways to facilitate such a project so that everybody benefits. If it turns out we have that role we shall do our best.
Ken Gracey
Comments
I'd point him back to the P2 right now
Once field-proven builds are out there for a number of Boards, the demands on Chip's time will fall off quite sharply.
Looks like a build with P2 style RAM-loaded ROM is well underway in the community.
Analog ? FPGA's don't quite do analog, but something like a SPI peripheral could HW stream from the simpler Fast ADCs
There are also isolated ADCs that can couple to a simple Counter+CLK, for high precision, modest speed uses.
I would add
- Elastic Sizing (User choice of RAM, COG count, and even COG RAM )
that some are already working on.This Elastic Sizing allows a fractional P1V into smaller LOGIC fabric, and would more naturally pair with a real P1 device - the P1V portion is then used for tasks where a std COG does not quite cut it.
Might be True PWM, or expanded Counters, (eg Fast Quadrature) etc.
This could be a good place to field-test the smart-pins planned for P2 ?.
Ditto to all that indeed but I can't see how Chip could share source from P2 though for testing unless it was on an individual NDA basis.
That's why I was thinking about the smart pins only, not the P2 core itself
The code for those is not complex, but the config details and 'use cases' will need to be quite well tested.
Another candidate is the serial IO opcodes from the first P2, covering that Analog Ken mentioned above.
Again, simple verilog, but giving good usage confirmation for P2.
Right on!
Very much like a super-P1 on FPGA where I can use the existing tools and get PortB, 160MHz and why not mul too.
Also having Chip back 100% on P2 would be nice.
BTW: I'm in a weird place right now because the whole reason I got into Propeller is because I didn't want to learn FPGA...
But, perhaps here is the best example one can think of to start learning...
Parallax have any plans for FPGA course?
Hey Ray,
I believe there's already a significant amount of FPGA educational material available, actually. None of it is in our style, though. I've met with Terasic's founder and he tells me about the significant size of their educational customer base. University professors have written books and provided quite a few examples.
Will we get into producing a formal FPGA educational program? Probably not: we're tight on resources; the market is small (but growing); and it would take additional staff we don't have. However, I think that the organic growth on the forums, user-contributed P1-variant projects we will see in the future, and some minor coverage from us could form at least a broader amount of support around the concept. But time changes our plans along with revenue, so this post will likely be dated quite quickly.
While you or I aren't likely to do anything beyond looking at the Verilog code, I could see you at least being involved in a "load and run" scenario on a DE0-Nano board at some point. You've done a lot with displays early on in the Propeller's existence, and if the only way to get to better display capabilities is a result of loading an FPGA image I can imagine you'll pick up a board. I think it'll take a reason or an example for you to jump in with the rest of them.
Ken Gracey
I think Ray's going to learn Verilog!
It would be good to make an FPGA curriculum. The problem is that it takes a lot of work for a little reward when it comes to designing logic, but that must be accepted if real learning is going to happen. I think much of the educational FPGA stuff out there leverages all kinds of IP, but doesn't promote the basics, which makes it all make sense.
Perhaps we are at a point in time where FPGAs are the *new* microcontrollers. I think there's probably a lot of value in helping people to use them. The problem is, I suspect, that people's/teachers' expectations are warped by the pervasive video-game mentality. We could have an awesome curriculum that starts out with basics and at the end of the first chapter the student understands how to make a PWM, for example. Meanwhile, the other guys have a slick IDE that lets you drag and drop huge components to compile big, splashy demos. Which would look more impressive, and which would actually teach something? Maybe we'd just need to rely on that <1% percent of the population that sees value in the details.
Somewhere I have one or two old Parallax FPGA dev boards that I picked up on Ebay a few years ago.
Given how good Parallax documentation is, would you guys still have the manuals/labs for them?
If so, I'd love a copy of the pdf's.
Thanks,
Bill
http://forums.parallax.com/attachment.php?attachmentid=105502&d=1303270946
Ken thanks for this announcement, good that P2 is still important to you guys. Certainly is to us.
Not quite yet, because FPGA will always be more expensive, but where I could see a Parallax opening, for both product and Educational markets, is to offer a Real P1 and a (fractional) P1v on the same board, using a lower-cost-end FPGA/CPLD.
A P1v COG makes a relatively small 32b IP core, and with a P1 there, you do not need 8 COGS in the FPGA.
I think a MachXO2-7000 can do a fP1v, and Altera have little info yet on their upcoming MAX 10, but they say it can run NIOS, and comes in 55nm flash process. If you have a line into Altera now, you could check into MAX 10.
Smartpack_Stratix.jpg
Smartpack_Cyclone.jpg
Just looking into that Analog item on Ken's list, I see TI (& others) have a number of SPI serial ADCs that simply stream data. (ie there is no data flow to these adc's)
Clocks of 32/40/48MHz with a pulsed CS, and some have a ChSel pin that can alternate like i2s.
Sample rates 2-3MHz, with bandwidths of 15-30MHz on the sampler.
They come from sub $1 @ 8b up to a few dollars for 14b 2 channels. Typically SOT23-6 or QFN16
That would mean a small Verilog cell to generate the CLK and CS ( & maybe ChSel) - CLK can be shared, and CS and DI are done in pairs per added ADC pathway.
For simplicity, it could even just run all the time, and have a single register read mapped to the result.
A 2 Chan 14b 2MSPS ADC appeals because it could do simple Audio, simple scope, metering, and logging.
Chip is then free to do other work, and the this thread will be fun to watch.
Opencores have tried to get a chip produced but last time I checked they were not getting much $ support.
I think we will have to leave putting the analog into the P1.5 for Chip & Beau. They have done the research for the P2.
I am well on the way to getting the whole design running with RAM instead of ROM, and separate objects for the log, antilog and sine tables. Chip has posted the font but I haven't had time to check. Hopefully I can post my progress later today with files. I am not at a point where I can actually test this out, but I can compile.
Of the 4 spare instruction slots, can we please reserve the latter two (ENC & ONES) for hubexec instructions.
One has to be a MUL instruction - maybe it can be MUL/MULS by using the "I" bit or the "C" bit???
That leaves one full instruction slot and some possible extensions using the SYSOP opcode "000011".
But we should be careful that this is a P1.5 and here compatibility reigns supreme.
BTW I wasn't aware Parallax made FPGA boards either.
BTW2: While this is a breather for Chip from the P2 design, we do want that to get done asap.
Indeed. They were very unique designs but didn't sell in a very large quantity. The purpose was mostly for Propeller 1 development and many customers remember coming into Parallax and seeing the video applications run off our FPGA boards.
And yes on BTW2, Chip wants the same. I sat down with him and ate some greasy Popeye's chicken in the airport the other night and asked about his schedule. In time we'll provide a very "programmatic" kind of update on our Parallax Insider News web page. In other words, as it looks today, but no promises.
Ken Gracey
Heck, yes! The collective of genius brains here could in fact become the new superstars of this forum.
(I don't consider myself one of them, but it's nice to rub shoulders with them at Expos.)
/me just encountered a moment of clarity.. perhaps one might even say a "parallax".
I remember seeing those. Never knew what they were for.
Until there is a 1.5 on the boards or considered for official design, wouldn't it be better and more useful to everyone to just implement the extra opcodes as USR1-USRn so other design investigations aren't forced into HUBEXEC schemes? If anyone does any tool changes, USR1, etc. seem more useful to me at this time.
A disclaimer would be good. I like the one that u-blox uses:
Disclaimer
This release contains certain forward-looking statements. Such forward-looking statements reflect the current views of management and are subject to known and unknown risks, uncertainties and other factors that may cause actual results, performance or achievements of the u-blox Group to differ materially from those expressed or implied. These include risks related to the success of and demand for the Group’s products, the potential for the Group’s products to become obsolete, the Group’s ability to defend its intellectual property, the Group’s ability to develop and commercialize new products in a timely manner, the dynamic and competitive environment in which the Group operates, the regulatory environment, changes in currency exchange rates, the Group’s ability to generate revenues and profitability, and the Group’s ability to realize its expansion projects in a timely manner. Should one or more of these risks or uncertainties materialize, or should underlying assumptions prove incorrect, actual results may vary materially from those described in this report. u-blox is providing the information in this release as of this date and does not undertake any obligation to update any forward-looking statements contained in it as a result of new information, future events or otherwise.
http://www.u-blox.com/en/press-and-events/press-release-archive/6418-u-blox-acquires-connectblue-adds-wi-fi-and-bluetooth-connectivity.html
It's a bit wordy but it makes it clear that this is an estimate and you shouldn't plan on it.
Thanks Cody. I like to be able to write in a way that we convey that reality but I agree it's more complex than I estimate. Some customers are basing their future on our next deliverable, so such a clear message about "forward looking statements" could help give us the latitude we typically need.
- Ken
So we might have a few forks around while we test things out. And who knows, maybe someone will come up with some other brilliant instructions that make more sense.
Ultimately Chip will have the final say. But meanwhile we can experiment.
then while executing code in bank1, reload bank2 from the hub in the background.
That sounds a little clunky, and chunks things even more, which is bad.
Given the higher cycles in P1V, perhaps a register frame pointer idea could be used.
Other micros have done this, and it allows the 512 register area to be moved.
In a P1V it may be possible and simple to allocate an unused COGs RAM to be 2 Register pages in another.
Something like 3 x 32 bits mapping tables, would allow 25% granularity ( ie the top three quarters ) with an option bit for blocking/return 0 or enable or similar ?
eg The most-skewed this could be set, would be 7 COGS of 128L and one COG that can reach 3200L, but that would be rare.
Thanks!
David
Here's my understanding...
In cog.v there are 5 states, m0-m4. The normal cycle is m0..m4 and are the normal states we refer to in the P1...
For the current instruction
m0: Fetch instruction S contents
m1: Fetch instruction D contents
m2: Execute instruction & Fetch next instruction
m3: Writeback Result
m0: .....etc
Now,
m4: Is a wait caused by the execution of a waitx instruction (eg waitcnt, waitpeq, etc)
Don't forget these are overlapped stages for the 2 instructions that overlap that we used to refer to as
I d S D e R I d S D e RHopefully you can now follow what happens in each state as coded in the // process and following sections.Does this help?