Postedit - please ignore - think I have corrupted something as my original working version is no longer working Oh Smile! In chasing down a problem I reverted hub.v to scrambled but was using unscrambled roms
Brian,
I have been trying to get my modified runner working. I used unscrambled.hex as the base, and then did a loadhex of my files, then a savehex of the result. It didn't work.
Anyway, as proof, I then just used unscrambled.hex. I am not using your generated output, just mine from the latest raw git base with unscrambling removed. It works for my high rom and my high rom with clusointerpreter. Of course I get the extra errors due to the 32byte hex lines but thought it still worked.
Is there something I am missing with unscrambled.hex?
Brian,
When you change the number of cogs, do you change anything other than the generate statement in dig.v ?
When I tried to create a new project using your toolbox, it failed to compile complaining about that line
for (I=0; I<4, I++)
as an error near the "+".
I don't think I am actually getting all the Quartus setup done correctly.
I was trying to only have hub rotating for 4 cogs by changing the line in dig.v
bus_sel <= {4'b0, bus_sel[2:0], ~|bus_sel[2:0]};
but no success so far.
Make sure you set Quartus to SystemVerilog.
Toolbox just changes the generate value at the moment.
You will probably get hub lock up with 4 cogs and 4 bits in the selector.
1:4 and 4 cycle instructions may not synchronize?
Makes sense. The bus is permanently enabled. That just means it is permanently enabled.
It does indeed work because I can pass data between cogs via hub, and the cog is indeed getting 1 hub access every 8 clocks.
Brian, thank you for your very helpful dev tool. As a complete novice in the FPGA arena, it has helped me immensely in understanding how things fit together. It takes a completely different mindset than the software development and execution path requires.
Brian,
Did you ever get the 16 cog version running?
There are quite a few changes for this to work. One is how you pass the cog# back and forth when starting because the next bit b3 is used for coginit as the "new" bit.
Just curious as to where you were up to.
Ray
I haven't looked at the 16 cog p1v for a while.
Quartus was giving me grief so I never got past the compile stage.
IIRC I was getting 9000+ warnings!
"Synthesized away" was the recurring theme there.
I'm currently working on p1v_toolbox building multiple p1v's for larger FPGA's such as DE2-115 and Parallax's 1-2-3 board.
Even that has turned out to be a bigger job than I expected
Cheers
Brian
Brian,
Couldn't you just use the Project boards (DE0-nano.cof and DE0-nano.qsf, etc) and some `define xxx for those boards?
That is where I am up to. There are some kludges to get it to work for 4 cogs, but it does work.
So I haven't really used your P1V Toolbox for that.
However, it has been immensely useful for generating the required hex files. If you then use Quartus to generate .mif files from the hex files, it reduces the warnings by another 4, although the altsyncram warnings remain, and I am not sure how to get rid of them.
I do have I/O warnings still. Perhaps you know how to get rid of these (think they are undefined I/Os not present in our/my designs)? Here they are..
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 (19016): Clock multiplexers are found and protected
Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2
Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2
Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|rom_high3_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_|rom_high2_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_|rom_high1_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 (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|rom_high0_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_|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 (12241): 4 hierarchies have connectivity warnings - see the Connectivity Checks report folder
Warning (13024): Output pins are stuck at VCC or GND
Warning (13410): Pin "ledg[4]" is stuck at GND
Warning (13410): Pin "ledg[5]" is stuck at GND
Warning (13410): Pin "ledg[6]" is stuck at GND
Warning (13410): Pin "ledg[7]" is stuck at GND
Warning (13410): Pin "ledg[4]" is stuck at GND
Warning (13410): Pin "ledg[5]" is stuck at GND
Warning (13410): Pin "ledg[6]" is stuck at GND
Warning (13410): Pin "ledg[7]" is stuck at GND
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 (15714): Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details
Warning (169177): 34 pins must meet Altera 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.
Ray
p1v_toolbox already supports all the boards and combinations of cogs,io,hub ram,hub slots etc.
For multiple p1v's in a build it's not that simple. Each p1v requires its own set of *.v files (i.e cog2.v,cog_ram2.v) to
avoid Quartus getting upset with "already defined" errors. It's all to do with the hierarchal layout of the Verilog code.
Also the top.tdf requires extensive modification for all the additional /O. Multiple dig.inc files and so on.
To fix sone of the warnings for a 4 cog build adjust the cog led stuff too.
In top.tdf change the following line
ledg [7..0] : output; -- cog leds
and in dig.v change this line
output [7:0] cog_led // led outputs to show which cogs are active
I haven't done anything with the I/O for different boards. Other than that, all my `define s work without changing files. But I had to position the config.v in the correct place for it to work properly.
I did have a problem with the counters requiring a manual change to the DE0-Nano.sdc (and other boards) file because `ifdef s didn't work there.
Hi OzPropDev
Any chance we can get (the $45) Macnica Odyssey added to the list of targets?
How about the new Altera 10m50 board as well (DK-DEV-10M50-A)?
Hi Tubular
I will look unto adding those boards to the mix. The code is in a state of flux at the moment. I'm hoping to have a update in a couple of weeks.
Comments
Now I have reorganised the runner ready for a test drive
Oh Smile! In chasing down a problem I reverted hub.v to scrambled but was using unscrambled roms
Brian,
I have been trying to get my modified runner working. I used unscrambled.hex as the base, and then did a loadhex of my files, then a savehex of the result. It didn't work.
Anyway, as proof, I then just used unscrambled.hex. I am not using your generated output, just mine from the latest raw git base with unscrambling removed. It works for my high rom and my high rom with clusointerpreter. Of course I get the extra errors due to the 32byte hex lines but thought it still worked.
Is there something I am missing with unscrambled.hex?
I recall being "tripped up" on the same scenario a while back.
I have posted my files here
http://forums.parallax.com/showthread.php/160754-Latest-P1V-git-files-Unscrambled-ROMs-Faster-Spin-Interpreter?p=1326878&viewfull=1#post1326878
Thanks to Brian's Verilog Toolbox, I have been able to merge the various hex files much easier than I have done before.
When you change the number of cogs, do you change anything other than the generate statement in dig.v ?
When I tried to create a new project using your toolbox, it failed to compile complaining about that line
for (I=0; I<4, I++)
as an error near the "+".
I don't think I am actually getting all the Quartus setup done correctly.
I was trying to only have hub rotating for 4 cogs by changing the line in dig.v
bus_sel <= {4'b0, bus_sel[2:0], ~|bus_sel[2:0]};
but no success so far.
Toolbox just changes the generate value at the moment.
You will probably get hub lock up with 4 cogs and 4 bits in the selector.
1:4 and 4 cycle instructions may not synchronize?
always @(posedge clk_cog or negedge nres) if (!nres) ena_bus <= 1'b0; else // ena_bus <= !ena_bus; ena_bus <= clk_cog; // RR20150419 don't divide by 2 (ie hub 1:8)I'm thinking ena_bus never toggles as it is clocked by the ppsedge of itself?It does indeed work because I can pass data between cogs via hub, and the cog is indeed getting 1 hub access every 8 clocks.
-Mike R...
Did you ever get the 16 cog version running?
There are quite a few changes for this to work. One is how you pass the cog# back and forth when starting because the next bit b3 is used for coginit as the "new" bit.
Just curious as to where you were up to.
I haven't looked at the 16 cog p1v for a while.
Quartus was giving me grief so I never got past the compile stage.
IIRC I was getting 9000+ warnings!
"Synthesized away" was the recurring theme there.
I'm currently working on p1v_toolbox building multiple p1v's for larger FPGA's such as DE2-115 and Parallax's 1-2-3 board.
Even that has turned out to be a bigger job than I expected
Cheers
Brian
Couldn't you just use the Project boards (DE0-nano.cof and DE0-nano.qsf, etc) and some `define xxx for those boards?
That is where I am up to. There are some kludges to get it to work for 4 cogs, but it does work.
So I haven't really used your P1V Toolbox for that.
However, it has been immensely useful for generating the required hex files. If you then use Quartus to generate .mif files from the hex files, it reduces the warnings by another 4, although the altsyncram warnings remain, and I am not sure how to get rid of them.
I do have I/O warnings still. Perhaps you know how to get rid of these (think they are undefined I/Os not present in our/my designs)? Here they are..
p1v_toolbox already supports all the boards and combinations of cogs,io,hub ram,hub slots etc.
For multiple p1v's in a build it's not that simple. Each p1v requires its own set of *.v files (i.e cog2.v,cog_ram2.v) to
avoid Quartus getting upset with "already defined" errors. It's all to do with the hierarchal layout of the Verilog code.
Also the top.tdf requires extensive modification for all the additional /O. Multiple dig.inc files and so on.
To fix sone of the warnings for a 4 cog build adjust the cog led stuff too.
In top.tdf change the following line and in dig.v change this line Cheers
Brian
My code should have worked since I set cog_led = {4'b0, cog_ena}; in dig.v
// cog leds `ifdef COGS_8 wire [7:0] cog_ena2 = cog_ena; `elsif COGS_4 wire [7:0] cog_ena2 = {4'b0, cog_ena}; `endif `ifdef INVERT_COG_LEDS assign cog_led = !cog_ena2; `else assign cog_led = cog_ena2; `endifI haven't done anything with the I/O for different boards. Other than that, all my `define s work without changing files. But I had to position the config.v in the correct place for it to work properly.
I did have a problem with the counters requiring a manual change to the DE0-Nano.sdc (and other boards) file because `ifdef s didn't work there.
#`ifdef COGS_8 #create_generated_clock -name ctra4_pll0 -source {pll|auto_generated|pll1|clk[0]} -divide_by 2 {dig:core|cog:coggen[4].cog_|cog_ctr:cog_ctra|pll_fake[28]} #create_generated_clock -name ctra4_pll1 -source {pll|auto_generated|pll1|clk[0]} -divide_by 4 {dig:core|cog:coggen[4].cog_|cog_ctr:cog_ctra|pll_fake[29]} ...Any chance we can get (the $45) Macnica Odyssey added to the list of targets?
How about the new Altera 10m50 board as well (DK-DEV-10M50-A)?
I will look unto adding those boards to the mix. The code is in a state of flux at the moment. I'm hoping to have a update in a couple of weeks.