Shop OBEX P1 Docs P2 Docs Learn Events
P1V for DE0-Nano. Volunteers invited to test updated architecture — Parallax Forums

P1V for DE0-Nano. Volunteers invited to test updated architecture

jac_goudsmitjac_goudsmit Posts: 418
edited 2017-09-18 06:40 in Propeller 1
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:
  • 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
«1

Comments

  • Cluso99Cluso99 Posts: 18,066
    Thanks for doing this Jac.
    I will try and fit it in to my currently busy schedule asap and let you know how it goes.
  • Heater.Heater. Posts: 21,230
    Love to.

    It might take a few days. I'm away from home just now.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2017-09-18 07:13
    Thanks Cluso99 and Heater! Take your time, I won't be able to work on this again until at least next weekend anyway.

    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
  • Nice work 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.stop
    
    
    Rock and roll! :cool:

    800 x 480 - 45K
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2017-09-18 15:00
    ozpropdev wrote: »
    Nice work Jac.
    Tested Ok :)
    Ran a small SPIN program to check pin assignments.
    Sends a serial ID out on each pin.

    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
  • I'll add that to the repository if you don't mind.
    Sure, no worries.
  • Super good work 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.
  • Tubular wrote: »
    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 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.
    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.

    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
  • Heater.Heater. Posts: 21,230
    Oh no, hope the DE-0 Nano is not going away. At least in concept. It's a great little board, nice big FPGA, lots of pins coming out, no redundant Smile.

    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.

  • There is no sign at this time that they're actually getting rid of the old DE0-Nano, that was just speculation. They are still for sale and quite ubiquitous, unlike other platforms such as the various BeMicro's.

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-10-03 09:27
    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 :(
  • Jac,

    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.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2017-10-03 15:48
    Cluso99 wrote: »
    Jac,
    I just compiled the DE0-Nano but not tested.

    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.
    Ouch!!! Quartus reports about 850 Warnings!!!

    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.
    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.

    Exactly, this is one of the changes Andy made.

    Basically if you do:
    wire enable;
    
    @always (posedge clk)
    enable <= ... something ...
    
    // Whenever you do this, the tools give you a warning
    @always (posedge clk or posedge enable)
    ... action XYZ ...
    
    // But this accomplishes the same thing without warning
    @always (posedge clk)
    if (enable)
       ... action XYZ ...
    

    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.
    Sorry but I haven't had sufficient time to get my hw out for testing yet :(

    That's okay, I haven't had much time to work on it either. Thanks for helping out!

    ===Jac

  • Cluso99Cluso99 Posts: 18,066
    Ok, now have my DE0-Nano compile down to 18 Warnings and I know I can fix a couple more :)
  • Cluso99Cluso99 Posts: 18,066
    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?
  • Cluso99 wrote: »
    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:
    • I used the SystemBuilder tool from Terasic to generate a new .QSF file.
    • I created a new top-level module DE0-Nano.sv that's specific for the DE0-Nano project.

    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
  • Cluso99Cluso99 Posts: 18,066
    Thanks 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.


  • David BetzDavid Betz Posts: 14,511
    edited 2017-10-04 22:32
    deleted
  • David Betz wrote: »
    Has anyone used the Prop123-A9 board for playing with P1v?

    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 hooked up my DE0-Nano to a PPDB and did a simple LED sequencer (Cylon Eyes) on 0-15 with no problems then I tried 16-31. The LEDs on 30 and 31 did not light up but I think that is because the Prop Plug is also using those pins.
  • Cluso99Cluso99 Posts: 18,066
    Yes, PROPPLUG uses 30 & 31
  • Cluso99Cluso99 Posts: 18,066
    Jac,
    I am down to 19 Warnings (attached)
    Warning (276027): Inferred dual-clock RAM node "dig:core|cog:coggen[0].cog_|cog_ram:cog_ram_|altsyncram:r[0][31]__1" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (10858): Verilog HDL warning at hub_mem.v(103): object rom_high used but never assigned
    Warning (19016): Clock multiplexers are found and protected
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[7].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[6].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[5].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[4].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[3].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[2].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[1].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[0].cog_|cog_ctr:cog_ctra|Mux6
    Warning (19016): Clock multiplexers are found and protected
    	Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2
    Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram0_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram3_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram2_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram1_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (292013): Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature.
    Warning (169177): 34 pins must meet Intel FPGA requirements for 3.3-, 3.0-, and 2.5-V interfaces. For more information, refer to AN 447: Interfacing Cyclone IV E Devices with 3.3/3.0/2.5-V LVTTL/LVCMOS I/O Systems.
    
    Any ideas on how to solve any of these warnings???

  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2017-10-07 01:30
    I got the number of warnings down to 29, that's about as low as I can get without cheating. I merged the changes into the Rel branch which is the default branch when you visit the repo at https://github.com/JacGoudsmit/P1V. EDIT: I undid the merge because it was generating a lot more warnings.

    These are my remaining warnings. They're similar to what Cluso99 had:
    Warning (10036): Verilog HDL or VHDL warning at hub_mem.v(92): object "rom_low_q" assigned a value but never read
    

    ^ 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.
    Warning (10030): Net "rom_high.data_a" at hub_mem.v(101) has no driver or initial value, using a default initial value '0'
    Warning (10030): Net "rom_high.waddr_a" at hub_mem.v(101) has no driver or initial value, using a default initial value '0'
    Warning (10030): Net "rom_high.we_a" at hub_mem.v(101) has no driver or initial value, using a default initial value '0'
    

    ^ 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.
    Warning (19016): Clock multiplexers are found and protected
    

    ^ 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.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[0].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[1].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[2].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[3].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[4].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[5].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[6].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276027): Inferred dual-clock RAM node "p1v:p1v_|dig:core|cog:coggen[7].cog_|cog_ram:cog_ram_|r_rtl_0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
    Warning (276020): Inferred RAM node "p1v:p1v_|dig:core|hub:hub_|hub_mem:hub_mem_|ram0_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "p1v:p1v_|dig:core|hub:hub_|hub_mem:hub_mem_|ram3_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "p1v:p1v_|dig:core|hub:hub_|hub_mem:hub_mem_|ram2_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    Warning (276020): Inferred RAM node "p1v:p1v_|dig:core|hub:hub_|hub_mem:hub_mem_|ram1_rtl_0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
    

    ^ 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.
    Warning (292013): Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature.
    

    ^ This can only be removed by suppressing it explicitly or by purchasing a commercial version of Quartus.
    Warning (169177): 70 pins must meet Intel FPGA requirements for 3.3-, 3.0-, and 2.5-V interfaces. For more information, refer to AN 447: Interfacing Cyclone IV E Devices with 3.3/3.0/2.5-V LVTTL/LVCMOS I/O Systems.
    

    ^ 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.
    Warning (169064): Following 36 pins have no output enable or a GND or VCC output enable - later changes to this connectivity may change fitting results
    

    ^ 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
  • Cluso99Cluso99 Posts: 18,066
    Thanks 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.
  • Cluso99Cluso99 Posts: 18,066
    I am down to 14 Warnings
    Warning (10858): Verilog HDL warning at hub_mem.v(138): object rom_high used but never assigned
    Warning (19016): Clock multiplexers are found and protected
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[7].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[6].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[5].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[4].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[3].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[2].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[1].cog_|cog_ctr:cog_ctra|Mux6
    	Warning (19017): Found clock multiplexer dig:core|cog:coggen[0].cog_|cog_ctr:cog_ctra|Mux6
    Warning (19016): Clock multiplexers are found and protected
    	Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2
    Warning (292013): Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature.
    Warning (169177): 34 pins must meet Intel FPGA requirements for 3.3-, 3.0-, and 2.5-V interfaces. For more information, refer to AN 447: Interfacing Cyclone IV E Devices with 3.3/3.0/2.5-V LVTTL/LVCMOS I/O Systems.
    

    Here are the changes (untested)...

    cog_ram.v
    // RR20171006  force use of simple altsyncram 
    
    module              cog_ram
    (
    input               clk,
    input               ena,
    input               w,
    input        [8:0]  a,
    input       [31:0]  d,
    output reg  [31:0]  q
    );
    
    wire we = ena && w;
    
    // 512 x 32 ram
    reg [31:0] mem [511:0]; 
    
    always @(posedge clk)
    begin
    	if (we)
    		mem[a] <= d;
    	q <= mem[a];
    end
    endmodule
    

    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]];
    end
    
  • Cluso99Cluso99 Posts: 18,066
    The following simplifies the Hub RAM (lower 32KB) and uses less LEs and Regs...

    hub_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;
    
    endmodule
    
    
  • Cluso99Cluso99 Posts: 18,066
    BTW the always @(posedge clk_cog) can also be always_ff @(posedge clk_cog).

    I 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)
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-10-06 11:25
    This removes the hub_mem.v warning 10858 about rom_high used but never assigned (same for rom-low when used)
    // RR20171006  dummy w for roms to suppress warning  (compiles but not verified)
    
    wire rom_low_we = 1'b0;									// never used
    wire rom_low_ena = (ena_bus && a[13:12] == 2'b10);
    
    always @(posedge clk_cog)
    begin
    	if (rom_low_ena) rom_low_q <= rom_low[a[11:0]];
    	if (rom_low_we)  rom_low[a[11:0]] <= d;				// dummy write
    end
    
    
    wire rom_high_we = 1'b0;									// never used
    wire rom_high_ena = (ena_bus && a[13:12] == 2'b11);
    
    always @(posedge clk_cog)
    begin
    	if (rom_high_ena) rom_high_q <= rom_high[a[11:0]];
    	if (rom_high_we)  rom_high[a[11:0]] <= d;				// dummy write
    end
    

    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 just undid the merge (i.e. I hard-reset the Rel branch and force-pushed it to Github) because I hadn't notice that there were a lot more warnings than I thought. These were caused by Andy changing the pll output of cog_ctr from a wire to a reg.

    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
  • Cluso99Cluso99 Posts: 18,066
    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 ;)
Sign In or Register to comment.