You can also view the design files with notepad.
:cool:
Look at the comment I found inside " * future 64-pin version" LOL
Yeah, it's a great relic! You see, there was a 64-pin version underway as I think you already know. Between tool compatibility issues and Chip's focus on P2 we didn't finish.
Right now, one line of Verilog gets commented out to eliminate the character ROM from the DE0-Nano compile, in order to make it fit. I tried doing the first half of the character ROM (characters $00..$7F), but there wasn't even room for that.
The BEMicro CV board is really chip and has plenty of RAM to spare, as well as logic. All one would have to do is make a unique top.qsf file for that board, and compile it with the other files, and they'd be running.
I think many of you will be kind of surprised at how little Verilog code it takes to make a Propeller 1 chip. The cog.v source file is only 4KB, for example.
Since the BEMicro CV might be a better match to the P1 Verilog than the DE0-Nano, is there any chance Parallax will be stocking them? If so, I'll hold off on buying one until Parallax gets them in their store.
Since the BEMicro CV might be a better match to the P1 Verilog than the DE0-Nano, is there any chance Parallax will be stocking them? If so, I'll hold off on buying one until Parallax gets them in their store.
The BEMicro CV has ~3x the RAM of the Nano, so should nicely avoid the P1- effects.
( I'm not sure if something limits using all the RAM, as the Nano on paper has "594-Kb embedded memory" or ~74K Bytes, BEMicro says "1,760 Kbit (Kb) M10K and 196 Kb MLAB memory" )
Parallax could stock a BEMicro CV + a FlashDrive with all the support files on it, for a little value-added ?
Addit : From another comment, Parallax could also pre-load the P1 code with a test program, into the FPGA board they provide, so a first-up use does not have to build or install Quartus first.
This would also help wrt 'student attrition', as a means to know a new board is still ok and 'download read'y helps in any lab
I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.
I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.
Yes, Chip said this above
["The BEMicro CV board is really chip and has plenty of RAM to spare, as well as logic. All one would have to do is make a unique top.qsf file for that board, and compile it with the other files, and they'd be running."]
- so the unique top file maps the FPGA pins & anything else FPGA unique, and the 'other files' are the core itself, so that would be common.
I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.
This is why we really should use github. One time, we combine files, make build conditional, with a script of some sort, or flags, however Quartus works. As new builds happen, the files can be kept track of, or merged back to make more builds possible, etc....
Then people make branches, can merge, and generally keep it sane.
Does Github only work with git, or does it support Mercural? Just wondering. I like that one.
As for why, that boils down to how Chip chose to do development. I'll bet he copies files, syncs things up, then makes specific edits, keeping it in folders from there.
That works well for one person, or a couple working closely. We've now opened it up, and it won't work so well IMHO.
This is why we really should use github. One time, we combine files, make build conditional, with a script of some sort, or flags, however Quartus works. As new builds happen, the files can be kept track of, or merged back to make more builds possible, etc....
Then people make branches, can merge, and generally keep it sane.
Yes I believe there is a strong argument for github for something like this.
And then there's also a strong argument for a friendly web page/blog/pdf doc linking across to reference builds, for those less used to github. Something as user friendly as your monitor doc, PH
I downloaded the files and built the DE0-Nano version successfully with Quartus 14.0. I might try it out tomorrow.
I downloaded the files but then got stuck in Quartus hell. Actually, I guess it's Mac OS X hell. Since there isn't a version of Quartus that runs on the Mac I tried to install it on Win XP in a VM. Unfortunately, I downloaded a 64 bit version and XP is 32 bits. I'm not installing Ubuntu 64 in another VM and after that will install the Linux version of Quartus. I might get to compiling the P1 Verilog sometime in the next decade. :-(
I sent some PMs about identifiers being used before being declared etcetera. (e.g. px in cog.v) Maybe someone with more time can try out some of the various free verilog simulators {icarus, verilator, cver, veriwell,....} and see if it's worth making edits so that they can handle this. I think there are some other constructs that those free simulators may not support. Of course someone would have to make a top level in verilog (to replace top.tdf) and a testbench for that to work, but first someone could just try "simulatorx dig.v" and see what pops up.
Edited to add: some people might find v2html (http://www.burbleland.com/v2html/v2html.html) useful for browsing around in Verilog code. If anyone knows about anything better that would be nice. I haven't tried it on this code since I had access to Verdi.
Okay, I found an older copy of Quartus on my Windows 7 machine and used it to build the P1 Verilog sources. I then downloaded the resulting image to my DE0-Nano board and the programming was successful. I unplugged the DE0-Nano and moved it to my Mac where I compiled and downloaded fibo and ran it getting the following results. I guess I'm off and running with the P1 Source code! Now I just have to study it to understand how it works. :-)
Hey Ken,
This is definitely going to require it's own forum. I am itching to start some threads to discuss some simple additions and I don't want to clog this thread.
Things like...
1. 48/64KB hub ram with small boot ROM. We can always load the upper ram with the rom if required.
2. 64 I/O
3. Overclocking
4. USB FS simple instruction support
5. Debugging support for FPGA only
I'm in favor of Open Source, but when I saw the initial post to the Distributors, I immediately hit reply and questioned on whether Parallax "just gave away the store."
I've been weighing this in my own mind ever since... (since I was asked not to say anything on the forums.)
Potential Upsides:
* Generates interest in Propeller chips.
* I can "emulate" my dream Propeller chip design.
* Generates some waves in the entire microcontroller community. Perhaps folks will take a second (or third) look at Parallax because of this.
* Because of this there will ALWAYS be a Propeller chip. (I can have one of these to play with forever.) Unlike my garbage C64 emulators that don't hold a candle to the real thing.
Potential Downsides:
* Nothing happens at all, and after all week or two of hoopla, things go back to "normal".
* While you can't create your own Propeller chip cheaply "today", this will likely change in the future. FPGA will become cheaper & more common. (fightens me most)
* Variations from the original design could create code confusion, instability, and incompatibility with existing code.
* Nothing happens at all, and after all week or two of hoopla, things go back to "normal".
* While you can't create your own Propeller chip cheaply "today", this will likely change in the future. FPGA will become cheaper & more common. (fightens me most)
* Variations from the original design could create code confusion, instability, and incompatibility with existing code.
I think you over-worry this.
FPGA's that can manage this, are mostly in BGA packages, and quite costly. The base price seems to change little, but the do fit more and more in.
They will never displace an exact P1.
What a FPGA can do, is allow companies to deploy a larger/faster/more tightly coupled P1, but notice that was not actually a job the P1 could meet.
Companies could deploy both P1 and FPGA.P1+ in designs, just like they use varying size PICs right now..
Variations are up to the person creating them to manage.
With a good macro assembler, opcode extensions should not have too much risk.
Maybe a Build/version number needs to go into ROM via the Verilog (if not already there )
The talk about Parallax starts in the video at 15:31.
If you are already setup with the DE0 for the prior FPGA images, all you have to do is remove the adapter board, look at the picture to see where the Prop plug goes, load the .jic file into the Atera programmer and go. Worked first time.
I'm on a Mac so I usually use BST. In this context, at least when using full serial duplex, a power cycle is required between downloads to the RAM of the FPGA-Prop1 (otherwise the Prop isn't found on subsequent ttys). Soft reboot has no effect. I tried using a different serial terminal program. That didn't help.
The specs say to limit power to the external power pins to 5.7V.
I think we need to give serious thought about how to keep Chip away from this discussion for a while:) Possibly we could password the thread and just not give it to him?
It will be years before I grasp most of this. In the meantime, my request for a variant is simply more Hub ram on the DE-115. Next would be hooking up the adapter boards, adding pins and hooking up the SDRAM.
Long before that happens I expect to have a Prop2.jic, which should take care of all that stuff anyway:)
3. Overclocking
4. USB FS simple instruction support
5. Debugging support for FPGA only
A means to Debug P1, could prove to be a very useful outcome.
There is certainly scope to include a P1 + Logic Analyser + RAM snooper into a single Build
Comments
:cool:
Look at the comment I found inside " * future 64-pin version" LOL
Yeah, it's a great relic! You see, there was a 64-pin version underway as I think you already know. Between tool compatibility issues and Chip's focus on P2 we didn't finish.
Ken Gracey
Chip, how fast does P1 run on a Nano?
The BEMicro CV has ~3x the RAM of the Nano, so should nicely avoid the P1- effects.
( I'm not sure if something limits using all the RAM, as the Nano on paper has "594-Kb embedded memory" or ~74K Bytes, BEMicro says "1,760 Kbit (Kb) M10K and 196 Kb MLAB memory" )
Parallax could stock a BEMicro CV + a FlashDrive with all the support files on it, for a little value-added ?
Addit : From another comment, Parallax could also pre-load the P1 code with a test program, into the FPGA board they provide, so a first-up use does not have to build or install Quartus first.
This would also help wrt 'student attrition', as a means to know a new board is still ok and 'download read'y helps in any lab
Yes, Chip said this above
["The BEMicro CV board is really chip and has plenty of RAM to spare, as well as logic. All one would have to do is make a unique top.qsf file for that board, and compile it with the other files, and they'd be running."]
- so the unique top file maps the FPGA pins & anything else FPGA unique, and the 'other files' are the core itself, so that would be common.
This is why we really should use github. One time, we combine files, make build conditional, with a script of some sort, or flags, however Quartus works. As new builds happen, the files can be kept track of, or merged back to make more builds possible, etc....
Then people make branches, can merge, and generally keep it sane.
Does Github only work with git, or does it support Mercural? Just wondering. I like that one.
As for why, that boils down to how Chip chose to do development. I'll bet he copies files, syncs things up, then makes specific edits, keeping it in folders from there.
That works well for one person, or a couple working closely. We've now opened it up, and it won't work so well IMHO.
(Don't I look a gift horse in the mouth?)
It's set up with a 5MHz input into what would be XI, so you can get 80MHz. I remember seeing an Fmax of something like 113MHz from the compile.
By identifying and declaring the multicycle paths through the ALU, you could probably get the Fmax to 160MHz (twice as fast).
Yes I believe there is a strong argument for github for something like this.
And then there's also a strong argument for a friendly web page/blog/pdf doc linking across to reference builds, for those less used to github. Something as user friendly as your monitor doc, PH
When someone has Quartus build stats on the cyclone V it uses, 5CEFA2F23C8N, you would know more.
Edited to add: some people might find v2html (http://www.burbleland.com/v2html/v2html.html) useful for browsing around in Verilog code. If anyone knows about anything better that would be nice. I haven't tried it on this code since I had access to Verdi.
This is sensational news!
My Nano and DE2 boards are really going to get a workout now!
Cheers
Brian
You are all very welcome and appreciated by us, too. Chip did all of the work to get this core ready.
I'm very happy to see that it's brought the top Prop-brainiacs back to the table for a while. Would be great to see Hippy come back for another round.
Ken Gracey
Thank you Limor and Phillip for the positive treatment!
Ken Gracey
This is definitely going to require it's own forum. I am itching to start some threads to discuss some simple additions and I don't want to clog this thread.
Things like...
1. 48/64KB hub ram with small boot ROM. We can always load the upper ram with the rom if required.
2. 64 I/O
3. Overclocking
4. USB FS simple instruction support
5. Debugging support for FPGA only
Fmax @ 160 on the Nano sounds great... this will be fun.
I've been weighing this in my own mind ever since... (since I was asked not to say anything on the forums.)
Potential Upsides:
* Generates interest in Propeller chips.
* I can "emulate" my dream Propeller chip design.
* Generates some waves in the entire microcontroller community. Perhaps folks will take a second (or third) look at Parallax because of this.
* Because of this there will ALWAYS be a Propeller chip. (I can have one of these to play with forever.) Unlike my garbage C64 emulators that don't hold a candle to the real thing.
Potential Downsides:
* Nothing happens at all, and after all week or two of hoopla, things go back to "normal".
* While you can't create your own Propeller chip cheaply "today", this will likely change in the future. FPGA will become cheaper & more common. (fightens me most)
* Variations from the original design could create code confusion, instability, and incompatibility with existing code.
It could be huge in the educational markets.
Also, will FPGA's replace Microcontroller's in the future. Is this just the beginning?
re: there was a 64-pin version underway as I think you already know.
Yes, It has provided for some interesting discussions over the years. Now we will see just how bad the Prop heads really wanted it. LOL
FPGA's that can manage this, are mostly in BGA packages, and quite costly. The base price seems to change little, but the do fit more and more in.
They will never displace an exact P1.
What a FPGA can do, is allow companies to deploy a larger/faster/more tightly coupled P1, but notice that was not actually a job the P1 could meet.
Companies could deploy both P1 and FPGA.P1+ in designs, just like they use varying size PICs right now..
Variations are up to the person creating them to manage.
With a good macro assembler, opcode extensions should not have too much risk.
Maybe a Build/version number needs to go into ROM via the Verilog (if not already there )
The talk about Parallax starts in the video at 15:31.
If you are already setup with the DE0 for the prior FPGA images, all you have to do is remove the adapter board, look at the picture to see where the Prop plug goes, load the .jic file into the Atera programmer and go. Worked first time.
I'm on a Mac so I usually use BST. In this context, at least when using full serial duplex, a power cycle is required between downloads to the RAM of the FPGA-Prop1 (otherwise the Prop isn't found on subsequent ttys). Soft reboot has no effect. I tried using a different serial terminal program. That didn't help.
The specs say to limit power to the external power pins to 5.7V.
I think we need to give serious thought about how to keep Chip away from this discussion for a while:) Possibly we could password the thread and just not give it to him?
It will be years before I grasp most of this. In the meantime, my request for a variant is simply more Hub ram on the DE-115. Next would be hooking up the adapter boards, adding pins and hooking up the SDRAM.
Long before that happens I expect to have a Prop2.jic, which should take care of all that stuff anyway:)
Wow.
Rich
Why stop at 64k ? No real reason to stop at 64io either..
Someone who has a 484 pin FPGA, has something like 224 ios on the device
A means to Debug P1, could prove to be a very useful outcome.
There is certainly scope to include a P1 + Logic Analyser + RAM snooper into a single Build