P1V for DE0-Nano. Volunteers invited to test updated architecture
jac_goudsmit
Posts: 418
Executive Summary: I would like to invite someone (preferably multiple persons) who have run a P1V on their DE0-Nano before, to test the new architecture in the "jacdev" branch, and report back on what you find. Thank you very much!
Long version:
Parallax released the hardware source code for the Propeller under GPL a few years ago, and I've been maintaining a Github repository at https://github.com/JacGoudsmit/P1V where you can find a version of this source code which has been ported to more platforms, made more maintainable and has had a few problems fixed and features added.
The Terasic DE0-Nano was one of the original target platforms that could be used to build the P1V project. One of the first things I did after I forked the Parallax P1V repository was to combine the source code for all platforms together, so that it wasn't necessary to maintain multiple versions of the same source code in multiple places in the repo.
But that meant that all targets shared the same "top.v" module which turned out not to be a very flexible way to implement the P1V on many targets. So I created a "P1V.v" module which puts all the portable aspects of P1V together in one module that takes a clock, a reset, and 32 input, output and direction wires. For the new platforms that have been created since then (BeMicroCV, BeMicroCV-A9, and the recently added Xilinx targets), I've used this architecture and it has proven to be very effective to create hardware-specific features.
Over the past weekend I've converted the DE0-Nano target from the "top.v" architecture to the "p1v.v" architecture but unfortunately I don't have a DE0-Nano so I can't test it.
So I would like to ask anyone with a DE0-Nano to download the new code from https://github.com/jacgoudsmit/P1V/archive/jacdev.zip, follow the instructions in the P8X32A_DE0_Nano directory (they're unchanged) and make sure it still works:
I don't want to merge it into the Release branch until I know it works, and I can't test it myself. I may decide to buy a DE0-Nano but at this time I don't have the budget so this is going to go back to the bottom of the bucket list unless I can get some help.
Any contributions will be rewarded with eternal gratitude and a mention in the readme file (I know, it's not much).
Thank you very much!
===Jac
Long version:
Parallax released the hardware source code for the Propeller under GPL a few years ago, and I've been maintaining a Github repository at https://github.com/JacGoudsmit/P1V where you can find a version of this source code which has been ported to more platforms, made more maintainable and has had a few problems fixed and features added.
The Terasic DE0-Nano was one of the original target platforms that could be used to build the P1V project. One of the first things I did after I forked the Parallax P1V repository was to combine the source code for all platforms together, so that it wasn't necessary to maintain multiple versions of the same source code in multiple places in the repo.
But that meant that all targets shared the same "top.v" module which turned out not to be a very flexible way to implement the P1V on many targets. So I created a "P1V.v" module which puts all the portable aspects of P1V together in one module that takes a clock, a reset, and 32 input, output and direction wires. For the new platforms that have been created since then (BeMicroCV, BeMicroCV-A9, and the recently added Xilinx targets), I've used this architecture and it has proven to be very effective to create hardware-specific features.
Over the past weekend I've converted the DE0-Nano target from the "top.v" architecture to the "p1v.v" architecture but unfortunately I don't have a DE0-Nano so I can't test it.
So I would like to ask anyone with a DE0-Nano to download the new code from https://github.com/jacgoudsmit/P1V/archive/jacdev.zip, follow the instructions in the P8X32A_DE0_Nano directory (they're unchanged) and make sure it still works:
- If you put a Prop Plug on the usual location, you should be able to detect it using the F7 key in Propeller Tool.
- If you download the cogledtest.spin module to RAM, it should still make the LEDs light up one by one
- If possible, you should verify whether the pin assignments for P0-P29 are still correct. Sorry there's no software for that at this time.
I don't want to merge it into the Release branch until I know it works, and I can't test it myself. I may decide to buy a DE0-Nano but at this time I don't have the budget so this is going to go back to the bottom of the bucket list unless I can get some help.
Any contributions will be rewarded with eternal gratitude and a mention in the readme file (I know, it's not much).
Thank you very much!
===Jac
Comments
I will try and fit it in to my currently busy schedule asap and let you know how it goes.
It might take a few days. I'm away from home just now.
By the way I just thought of another reward: If this tests okay and gets merged into Rel, I'm going to do another architecture tweak: I want to make an alternative version of the P1V module that "breaks out" the hub and cog memory to the top level. That way it should be possible to use the SDRAM on the DE0-Nano as hub memory, and free up enough on-board RAM to make it fully support the P1V, including the character ROM.
I forgot to mention I want to change the DE2-115 on the new architecture too (and I'm definitely NOT going to buy one of those; they're too expensive for a toy). And I have another Altera target that I'm going to be working on.
===Jac
Tested Ok
Ran a small SPIN program to check pin assignments.
Sends a serial ID out on each pin.
con _clkmode = xtal1 + pll16x _clkfreq = 80_000_000 obj fds: "fullduplexserial" pub main|pin repeat repeat pin from 0 to 29 fds.start(31,pin,0,115200) fds.str(string("Pin#")) fds.dec(pin) waitcnt(cnt+clkfreq/30) fds.stopRock and roll! :cool:Hey that's a great idea for a pin test program! I'll add that to the repository if you don't mind.
Thanks!
===Jac
Being from the Altera side, it really helps to have something familiar like P1V with instructions for Xilinx set out like you have in photos on github. You should post those annotated photos directly in this thread too
I should be able to loan you a DE0-Nano before long if you're interested. I may also be able to provide remote access to a dev system with DE2-115 and webcam attached.
I know, the documentation needs work, for the Altera targets as well as the Xilinx targets. The organization of the source files also needs work. I don't want to post pictures or instructions to this thread (or any other place outside Github) because when things change for any reason whatsoever, Google and other search engines will still find the outdated information whereas if I update the information on Github, all references will automatically point to the updated docs. Digilent has the same problem: their documentation shows screen shots for an earlier version of Vivado, and Vivado has changed its user interface significantly, recently.
Thank you for the generous offer! I just noticed that Terasic made the DE0-Nano cheaper (probably because they're going to discontinue it and replace it with the DE0-Nano-Soc; someone should really tell them about namespace pollution) so I may just buy one soon. I may take you up on the offer for the DE2-115 but we'll see.
===Jac
Here I am, getting my feet wet with Verilog and such. Experimenting with P1 and RISC V cores and such and they want to replace the nano with something that has a stupid ARM processor built in.
I guess the FPGA world has moved on. What is the a big, simple, small, cheap FPGA board today?
Nah, never mind, I'm going to be getting into Lattice parts when I have the time. http://icoboard.org/ Gotta love the Free and Open Source tool chain. Synthesize your design on a Raspberry Pi! Much easier than all that Quartus stuff. I guess there is not much of a P1 that fits in an 8k Lattice part.
The same is going on on the Xilinx side: Besides the Arty, there are now two(?) other Arty's that look the same but have different FPGAs and (arguably better) features.
Besides this, there's also the problem that older FPGAs are no longer supported by new versions of the software (Altera/Intel as well as Xilinx). For the new target that I'm working on, I also have to install an older version of the Quartus software and that software takes up a LOT of disk space :-(.
Oh well... Such are the burdens of a maintainer that targets various hardware. For those who only have one or a few FPGA boards, things will stay easy.
===Jac
I just compiled the DE0-Nano but not tested.
Ouch!!! Quartus reports about 850 Warnings!!!
I have been getting only 23 Warnings although I did achieve 18 Warnings with the Video removed.
Also I noticed that in cog.v that some of the always@ statements have "or negedge ena" removed.
Postedit: ok I can see by they are not required.
Sorry but I haven't had sufficient time to get my hw out for testing yet
Since I have a DE0-Nano collecting dust I'll toss my hat into the ring and test it too. Like most others I have a busy schedule but I'll fit it into what free time I have.
For those who are testing it, I want to remind you to check out the "jacdev" branch (or use the ZIP file link that I posted above), not the default "Rel" branch.
Andy Silverman is putting in a lot of work to eliminate warnings on the Xilinx targets. If you're still seeing 850 warnings, it's because not all his source code has been integrated into the "jacdev" branch yet.
Also the branch/merge tree on Github looks like a wild entangled mess right now, because he added a binary file to his repo which I didn't want, and I had to merge around it. If you use GitExtensions, the tree gets rendered in a much neater way.
Exactly, this is one of the changes Andy made.
Basically if you do:
Chip's original code had the sequences that generate warnings, in a lot of locations. Andy fixed them all. So now the code isn't the same as the original but I decided since it works verifiably the same, it's better to have the changed code and not have hundreds of warnings, than to strictly keep the original Parallax code. Obviously I will make sure that the Rel branch will always work like a regular Prop 1.
That's okay, I haven't had much time to work on it either. Thanks for helping out!
===Jac
Today I spent some time on your DE0-Nano version.
I compiled DE0-Nano and it instantly compiled with 3 Warnings.
Then I forced a whole recompile (smartcompile setting off) and it produced over 800 Warnings. What am I doing wrong?
You're not doing anything wrong
When Parallax released the files, they generated LOTS of warnings, and they failed timing. But you could ignore the warnings and the build still worked.
In the "jacdev" branch, I changed the DE0-Nano project (revision) as follows:
In the original Parallax code, all the targets had a "top.v" module and each of those was slightly different. When I moved all the HDL code from all targets into one directory (so I wouldn't have to maintain 3 or more sets of files), I made all projects use the same top.v file, and that was a mistake. I should have created a DE0-Nano top file, a DE2-115 top file and a BeMicroCV top file.
In the old DE0-Nano.qsf file, only the pins that were necessary for the Propeller were defined. All the other ones were left out, so if anyone wanted to add features to the P1V project that would use other hardware on the board, they would have to edit the .qsf file themselves. But Terasic has a tool called SystemBuilder, specifically for the DE0-Nano, that can generate a .qsf file based on which devices you need, so I generated one with all the devices (SDRAM, accelerometer, DIP switches, pushbuttons, EEPROM etc) enabled. This way, the new .qsf file can stay more or less constant and users can adapt the top-level SystemVerilog module to their needs, instead of having to maintain the .qsf file in addition to the top level file.
There are still a lot of warnings (I think the count is 851), because I branched off the "jacdev" branch a while ago, before Andy made a lot of changes eliminating pretty much all the HDL warnings, in the Xilinx branch. Unfortunately his changes aren't in the "jacdev" branch and I don't want to merge them together yet, because eventually everything will go into the Rel branch anyway.
Besides the warnings about problems in the HDL that Andy fixed, there are also warnings about the project not meeting timing restrictions. Chip didn't do anything about tweaking the timing and the Timing Analyzer in Quartus has always failed, ever since Parallax released the sources. Nevertheless, as you know, the code generates a binary that works. I learned some things from Andy about setting up timing in Vivado, and I think I know enough to tweak the timing in the Quartus projects too now, so with a bit more time we can get the "thumbs up" for all the Altera targets too, as well as the Xilinx targets.
So, in short, don't worry too much about the warnings, we'll eventually make them go away. And if you can help, they'll go away faster of course! :-)
Thanks for helping out!
===Jac
I can compile my own DE0-Nano based on the older code from Chip with a couple of fixes he posted. I am down to 18 Warnings and I can solve a couple more.
I added the .qsf file for the Prop123-A9 to the repo in March 2016, but I never wrote a top file and never added it to the Quartus project file. I'm dedicated to the project but I have to prioritize targets that I actually own over the ones that may be more interesting but are too expensive for me.
You're more than welcome to add a target yourself, though! It shouldn't be too hard, there's already a top file for the fpga123-A7 that you can copy and modify. The .qsf file is the hardest part of supporting a new Altera target, and that's already there, courtesy of Chip.
===Jac
I am down to 19 Warnings (attached) Any ideas on how to solve any of these warnings???
These are my remaining warnings. They're similar to what Cluso99 had:
^ This is us loading the font ROM and then not using it for the DE0-Nano. I have a change in mind to implement memory a different way (at the top level) which should make it easier to implement larger hub memory and do things like disabled parts of the ROM for specific targets. It should reduce or even eliminate all the memory warnings.
^ More warnings because it detects that we try to implement memory. These might be eliminated by initializing the memory explicitly but I don't think it's important enough. I may do it after the change that I mentioned above.
^ It may be possible to remove these warnings by adding extra clock declarations but as far as I can tell, Quartus is just saying that it's doing what we want, so I'm not going to bother.
^ More harmless warnings about RAM gonna RAM: It's detecting (possibly falsely) that we want synchronous dual-port RAM and taking measures to make everything work the way that it thinks we want to make it work. Again, I'll look into it once I make the change to move the RAM to the top level.
^ This can only be removed by suppressing it explicitly or by purchasing a commercial version of Quartus.
^ This is Quartus reminding us to read an Application note that tells you how to connect 3.3V logic to a Cyclone IV. It can only be removed by explicitly suppressing the warning.
^ These are just GPIO pins that are not in use, so their direction wire is unused. I could eliminate these by disabling the pins in the .qsf file but meh. Not a big deal.
Thanks everyone for your cooperation!
Enjoy!
===Jac
The last 3: I know (and did) fix the last one. I have tried to fix thee other two. Thought there was still a problem with the app note one so pleased it's ok. Also tried to remove the logiclock one but couldn't.
The RAM ones: Yes, I can fix a couple. Understand the warning when you never read the ROM. initialising differently as I did (think it's specific to altera) can remove a couple. I have been playing with the dual clock ram problem and have read some more so will give it a go and let you know. I have a lot of variations of the hub ram and rom. Once I get this better I will post the code.
Clock multiplexers: would be good to get rid of the Warnings as it's difficult to understand them. IIRC there are 9 Warnings here.
Once again, thanks for your help.
Here are the changes (untested)...
cog_ram.v
hub_ram.v - change the lower 32KB Hub RAM as follows:
// RR20171006 force use of simple altsyncram wire we3 = (ena_bus && !a[13] && w && wb[3]); wire we2 = (ena_bus && !a[13] && w && wb[2]); wire we1 = (ena_bus && !a[13] && w && wb[1]); wire we0 = (ena_bus && !a[13] && w && wb[0]); always @(posedge clk_cog) begin if (we3) ram3[a[12:0]] <= d[31:24]; ram_q3 <= ram3[a[12:0]]; end always @(posedge clk_cog) begin if (we2) ram2[a[12:0]] <= d[23:16]; ram_q2 <= ram2[a[12:0]]; end always @(posedge clk_cog) begin if (we1) ram1[a[12:0]] <= d[15:8]; ram_q1 <= ram1[a[12:0]]; end always @(posedge clk_cog) begin if (we0) ram0[a[12:0]] <= d[7:0]; ram_q0 <= ram0[a[12:0]]; endhub_mem.v (part shown only - not tested on hw)
// RR20171006 force use of simple altsyncram (compiles but not verified) // 8192 x 32 ram with byte-write enables ($0000..$7FFF) reg [3:0][7:0] ram [8191:0]; reg [31:0] ram_q; wire wena = (ena_bus && !a[13] && w); always @(posedge clk_cog) begin if (wena) begin if (wb[3]) ram[a[12:0]][3] <= d[31:24]; if (wb[2]) ram[a[12:0]][2] <= d[23:16]; if (wb[1]) ram[a[12:0]][1] <= d[15:8]; if (wb[0]) ram[a[12:0]][0] <= d[7:0]; end ram_q <= ram[a[12:0]]; end ..... // memory output mux reg [1:0] mem; always @(posedge clk_cog) if (ena_bus) mem <= a[13:12]; assign q = !mem[1] ? ram_q // {ram_q3, ram_q2, ram_q1, ram_q0} `ifndef DISABLE_FONT_ROM : !mem[0] ? rom_low_q // comment out this line for DE0-Nano (sacrifices character rom to fit device) `endif : rom_high_q; endmoduleI am not sure whether there is any difference. I found the example for the ram online and it used the always_ff construct.
I have suppressed the warnings 292013 LogicLock and 169177 pins meeting AN 447.
So I now have 12 warnings.....
Clock Multiplexer warnings account for 2+9=11
Hub ROM which is because it is read only (probably fixable)
Now just the 19016 Clock multiplexers are found and protected (2+9= 11 warnings)
No ideas how to fix these without suppressing the warnings
I understand that this was a good change; it eliminated a lot of other warnings so I'm keeping it. But I have to add timing constraints for that register now and I'm still a little lost as to what needs to go in: yes I can simply constrain it to 128MHz and it will close the timing just fine but I get the feeling that that's not the way to do it: it should be a generated clock based on clk_pll from p1v (?).
Work in progress; contributions are welcome (especially in the form of pull requests).
===Jac
Just tested rel 20171005. I needed to recompile as the DE0-Nano.cof conversion complained about missing files IIRC.
Recompiled --> 14753 LEs, 5446 regs, 0/57 errors. Generated output_files/DE0-Nano.jic and programmed FPGA correctly.
Compiled and downloaded and ran a few spin programs successfully. Excellent
Now to test my changes