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.
I decided to just suppress the warnings about AN 447 and LogicLock. As far as I know there is no way around them, and no chance that they might ever be important in the future.
As for the warnings caused by unused pins: I've sort of given up on those, because first of all, even though there are easy ways to change the declaration of the GPIO pins in the top level module header, it would just make things ugly again and I'd rather deal withe the warning about unassigned pins (which might go away when we add Port Band other features) than undo the tidy-up that this change is really all about.
The RAM ones: Yes, I can fix a couple.
I'll look into your quick fixes for the RAM and ROM warnings. I'll have to test them on one of my other boards (especially on the Arty, to make sure Vivado also still does the right thing to infer the RAM and ROM) because I still don't have a DE0-Nano.
But the main reason I'm not focussing on the RAM and ROM at this time is that I think it would be a good idea to move the hub memory to the top level. Many customizations of the P1V are likely to have a modified ROM or RAM:
The DE0-Nano can't use the font ROM
There have already been various projects to increase the hub RAM size or use external hardware for it
It would be great to easily swap boot code to make it possible to store Propeller projects on MicroSD cards, flash ROM or other media.
Clock multiplexers: would be good to get rid of the Warnings as it's difficult to understand them.
As far as I understand, the clock multiplexers are important for timing analysis and Quartus has a good reason to protect them. I think there's a way to manually protect them with some incantations in the .sdc file. But my Timing Analyzer Fu is not yet up to snuff. I'm more worried about the new warnings about the unconstrained pll reg in the cog_ctr.v module.
Jac,
We cross posted.
I have my extras options governed by global macros. It's not quite the right way but it works.
I have a number of different ROM section files including my faster Interpreter. I have an option to use unscrambled files as it is easier that way.
I am getting ready to try dual port ram for cogs. Once I am using it I will be trying the fetch of S & D in the same cycle, reducing the base instructions to 3 clocks instead of 4.
jac,
I am curious. I believe they are equivalent, but which is better?
from hub.v
always @(posedge clk_cog)
if (ena_bus)
rc <= bus_r;
always @(posedge clk_cog)// or negedge nres)
if (!nres)
ec <= 1'b0;
else if (ena_bus)
ec <= bus_e;
always @(posedge clk_cog)
if (ena_bus)
wc <= bus_w;
always @(posedge clk_cog)
if (ena_bus)
sc <= bus_s;
always @(posedge clk_cog)
if (ena_bus)
ac <= bus_a;
always @(posedge clk_cog)
if (ena_bus)
dc <= bus_d;
always @(posedge clk_cog)
begin
if (!nres)
ec <= 1'b0;
else if (ena_bus)
ec <= bus_e;
if (ena_bus)
begin
rc <= bus_r;
wc <= bus_w;
sc <= bus_s;
ac <= bus_a;
dc <= bus_d;
end
end
jac,
I am curious. I believe they are equivalent, but which is better?
As far as I can see, yes, they are equivalent. But you should probably verify by building it both ways and comparing the schematics in the RTL viewer.
Which one is better is a matter of taste. Personally, I would probably prefer your version.
But for this project I probably wouldn't accept a change that's only written to improve legibility. I don't really think there was anything wrong with the original way it was written, and I'm sure you agree there's also a risk involved in making changes like this, especially if you want to do it on a large scale. And if you only do it in one place, it'll result in an inconsistent layout, which also doesn't really help anyone.
I think Chip pretty consistently wrote one assignment per always-statement, and I'm happy to leave it that way unless there's an obvious improvement (e.g. reduction of the number of warnings). He has more experience with Verilog than I have, so hopefully he knows what he's doing. And changes like that might turn him off from making any future contributions the P1V project.
Thanks Jac.
I will keep the original for the repo, but use the easier to understand version for myself.
I have added some more comments too.
I edit with Notepad++ and have the setting to save without tabs.
Once I have all the basics done I will let you know so we can merge into the repo. Not sure how to do this so when ready I will enlist your help.
BTW not sure if you know, but the $readmemh can be done with multiple sections using a start address and optional end address. I also have unscrambled code too, and I have my own faster Interpreter version too. All seem to work fine.
Once I have all the basics done I will let you know so we can merge into the repo. Not sure how to do this so when ready I will enlist your help.
The best way to get credit for your contributions is:
Create a Github account if you don't have one yet
Fork my P1V repo into your own account
Use a program like GitExtensions to clone the repo from your Github account to your computer at home
Make your modifications on your computer at home, and commit them
Push your modifications to your Github repo
Create a pull request from your changes
But of course you can also post your code here; it will just seem as if I added it instead of you (don't worry, I'll give you credit in the commit comments and in the readme file).
BTW not sure if you know, but the $readmemh can be done with multiple sections using a start address and optional end address. I also have unscrambled code too, and I have my own faster Interpreter version too. All seem to work fine.
I didn't write the $readmemh code (it came from the old repo by MindRobots) but that's good to know. It might make ROM initialization a lot simpler.
The unscrambled ROM image files are already in the repo, also copied from the old repository. They're just not in use at the moment.
The faster interpreter may be something to implement as an option (selectable by a top-level parameter or by a hardware switch something).
Thanks!
(By the way I probably won't have time to work on this for the next few days :-( )
Comments
I decided to just suppress the warnings about AN 447 and LogicLock. As far as I know there is no way around them, and no chance that they might ever be important in the future.
As for the warnings caused by unused pins: I've sort of given up on those, because first of all, even though there are easy ways to change the declaration of the GPIO pins in the top level module header, it would just make things ugly again and I'd rather deal withe the warning about unassigned pins (which might go away when we add Port Band other features) than undo the tidy-up that this change is really all about.
I'll look into your quick fixes for the RAM and ROM warnings. I'll have to test them on one of my other boards (especially on the Arty, to make sure Vivado also still does the right thing to infer the RAM and ROM) because I still don't have a DE0-Nano.
But the main reason I'm not focussing on the RAM and ROM at this time is that I think it would be a good idea to move the hub memory to the top level. Many customizations of the P1V are likely to have a modified ROM or RAM:
As far as I understand, the clock multiplexers are important for timing analysis and Quartus has a good reason to protect them. I think there's a way to manually protect them with some incantations in the .sdc file. But my Timing Analyzer Fu is not yet up to snuff. I'm more worried about the new warnings about the unconstrained pll reg in the cog_ctr.v module.
===Jac
We cross posted.
I have my extras options governed by global macros. It's not quite the right way but it works.
I have a number of different ROM section files including my faster Interpreter. I have an option to use unscrambled files as it is easier that way.
I am getting ready to try dual port ram for cogs. Once I am using it I will be trying the fetch of S & D in the same cycle, reducing the base instructions to 3 clocks instead of 4.
I am curious. I believe they are equivalent, but which is better?
from hub.v
always @(posedge clk_cog) if (ena_bus) rc <= bus_r; always @(posedge clk_cog)// or negedge nres) if (!nres) ec <= 1'b0; else if (ena_bus) ec <= bus_e; always @(posedge clk_cog) if (ena_bus) wc <= bus_w; always @(posedge clk_cog) if (ena_bus) sc <= bus_s; always @(posedge clk_cog) if (ena_bus) ac <= bus_a; always @(posedge clk_cog) if (ena_bus) dc <= bus_d;always @(posedge clk_cog) begin if (!nres) ec <= 1'b0; else if (ena_bus) ec <= bus_e; if (ena_bus) begin rc <= bus_r; wc <= bus_w; sc <= bus_s; ac <= bus_a; dc <= bus_d; end endAs far as I can see, yes, they are equivalent. But you should probably verify by building it both ways and comparing the schematics in the RTL viewer.
Which one is better is a matter of taste. Personally, I would probably prefer your version.
But for this project I probably wouldn't accept a change that's only written to improve legibility. I don't really think there was anything wrong with the original way it was written, and I'm sure you agree there's also a risk involved in making changes like this, especially if you want to do it on a large scale. And if you only do it in one place, it'll result in an inconsistent layout, which also doesn't really help anyone.
I think Chip pretty consistently wrote one assignment per always-statement, and I'm happy to leave it that way unless there's an obvious improvement (e.g. reduction of the number of warnings). He has more experience with Verilog than I have, so hopefully he knows what he's doing. And changes like that might turn him off from making any future contributions the P1V project.
===Jac
I will keep the original for the repo, but use the easier to understand version for myself.
I have added some more comments too.
I edit with Notepad++ and have the setting to save without tabs.
Once I have all the basics done I will let you know so we can merge into the repo. Not sure how to do this so when ready I will enlist your help.
BTW not sure if you know, but the $readmemh can be done with multiple sections using a start address and optional end address. I also have unscrambled code too, and I have my own faster Interpreter version too. All seem to work fine.
Ray
The best way to get credit for your contributions is:
But of course you can also post your code here; it will just seem as if I added it instead of you (don't worry, I'll give you credit in the commit comments and in the readme file).
I didn't write the $readmemh code (it came from the old repo by MindRobots) but that's good to know. It might make ROM initialization a lot simpler.
The unscrambled ROM image files are already in the repo, also copied from the old repository. They're just not in use at the moment.
The faster interpreter may be something to implement as an option (selectable by a top-level parameter or by a hardware switch something).
Thanks!
(By the way I probably won't have time to work on this for the next few days :-( )
===Jac