Building 5 x P1V's in a DE2-115

ozpropdev · 2014-08-21 04:45

I just got 5 x P1V's running in a DE2-115. I tried to squeeze 6 in but ran out of space.
These were "standard" 80MHz 32xIO versions with an additional Verilog module for propplug management.
For the record it took 80+ minutes to compile on my old Q6600 quad core @2.4GHz on Win 7.
Heres the resource results.

Flow Status	Successful - Thu Aug 21 19:18:16 2014
Quartus II 32-bit Version	13.1.0 Build 162 10/23/2013 SJ Web Edition
Revision Name	p1vclean
Top-level Entity Name	p1vclean_4
Family	Cyclone IV E
Device	EP4CE115F29C7
Timing Models	Final
Total logic elements	74,782 / 114,480 ( 65 % )
Total combinational functions	67,593 / 114,480 ( 59 % )
Dedicated logic registers	27,079 / 114,480 ( 24 % )
Total registers	27079
Total pins	28 / 529 ( 5 % )
Total virtual pins	0
Total memory bits	3,276,800 / 3,981,312 ( 82 % )
Embedded Multiplier 9-bit elements	0 / 532 ( 0 % )
Total PLLs	1 / 4 ( 25 % )

The extra Verilog uses KEY1 to select a propeller (0-4) which is displayed on a 7 segment led display.
The selected propeller is connected to the propplug and KEY0 is a reset button only for that propeller.
A second 7 segment display shows how many cogs are active in the selected propeller.
The 8 x green leds still indicate the actual cogs in use for the current selected propeller.
See Verilog code and schematic for more details. Apologies on my rough Verilog code (its my first attempt!)

Cheers
Brian

P.S. I'm adding PortB back in to all P1V's next so they can all "socialize" with each other. FPGA is fun

pik33 · 2014-08-21 05:21

Good

5 props, 40 cogs...
How much routing resources it eats and how long it compiles?

Cluso99 · 2014-08-21 07:25

Very interesting. IIRC the old power hungry P2 coiuld only get 6 cogs in the DE2.
Presuming you have 64KB of hub in each, that is 320KB, plus 40 cogs of 2KB is 80KB, for a total of 400KB RAM.

ozpropdev · 2014-08-21 07:28

@pik33
Compile took over 1 Hour 20 Minutes.
The only resource data I've got is above.
Now I have a valid reason to get a new faster PC

Cheers
Brian

ozpropdev · 2014-08-21 07:31

Cluso99 wrote: »

Very interesting. IIRC the old power hungry P2 coiuld only get 6 cogs in the DE2.
Presuming you have 64KB of hub in each, that is 320KB, plus 40 cogs of 2KB is 80KB, for a total of 400KB RAM.

The last version of the old P2 only had 4 cogs! They were BIG...:)

jazzed · 2014-08-21 07:34

Cool.

PentaProp!

mindrobots · 2014-08-21 07:45

Been there, done that, got the pictures.

But this is REALLY cool and now I want to do it to a DE2!

Can you share construction techniques for how to get all that Verilog hooked together? I'd like to try and get this going in time for OBC's Propeller Expo (August 30)

ozpropdev · 2014-08-21 08:02

mindrobots wrote: »

Been there, done that, got the pictures.

But this is REALLY cool and now I want to do it to a DE2!

Can you share construction techniques for how to get all that Verilog hooked together? I'd like to try and get this going in time for OBC's Propeller Expo (August 30)

No worries Rick

I post that info tomorrow with some more stuff.
BTW Nice pictures

Cheers
Brian

pik33 · 2014-08-21 08:53

I read the attached .v file and ...

don't use = to assign a value. Use <= instead

There are 2 assignment operators in Verilog: = and <=. The first is so called blocking. If you use this, your assignments will be executed sequentially, as in programming language. This is not natural for FPGA and may cause unwanted side effects which I had to learn some time ago.

ozpropdev · 2014-08-22 06:05

@pik33 <= Thanks!

@mindrobots
I created symbols for the "prop" and "propplug_manager" (FILE - CREATE/UPDATE -Symbol file for current file)
Then FILE - NEW - Block diagram, then click on the Symbol tool (AND gate icon) to select a symbol then paste.
I then made the schematic file the top entity. (Right click on schematic filename in the "Project Navigator" window.
Not sure yet how to do all that in Verilog as a "top" entity yet. (No schematic required).
Still learning as I go... below is a cleaned up/refined version of the proplug manager whuch seems to work fine.

//Controls 5 x propellers from a single propplug.

module	propplug_manager

(

input pb_reset,
input pb_prop_select,
input	[7:0] prop0_cog_ind,
input	[7:0] prop1_cog_ind,
input	[7:0] prop2_cog_ind,
input	[7:0] prop3_cog_ind,
input	[7:0] prop4_cog_ind,
input propplug_resn,
input propplug_rx,
input prop0_tx,
input prop1_tx,
input prop2_tx,
input prop3_tx,
input prop4_tx,

output [7:0] cog_status_leds,
output [6:0] prop_7_seg,
output prop0_resn,
output prop0_rx,
output prop1_resn,
output prop1_rx,
output prop2_resn,
output prop2_rx,
output prop3_resn,
output prop3_rx,
output prop4_resn,
output prop4_rx,
output propplug_tx,
output [6:0] cogs_used
);


reg [3:0] selected_prop;
reg [3:0] cogs_inuse;

initial selected_prop = 0;


//select a propeller and display on 7 segment display
always @(posedge pb_prop_select) begin;

	selected_prop++;
	if (selected_prop == 5) selected_prop <= 0;
end

always @(*) begin;

	if (selected_prop == 0) prop_7_seg <= ~7'b0111111;
	if (selected_prop == 1) prop_7_seg <= ~7'b0000110;
	if (selected_prop == 2) prop_7_seg <= ~7'b1011011;
	if (selected_prop == 3) prop_7_seg <= ~7'b1001111;
	if (selected_prop == 4) prop_7_seg <= ~7'b1100110;
	if (selected_prop == 5) prop_7_seg <= ~7'b1101101;
	
end

always @(*) begin;

	if (cogs_inuse == 0) cogs_used <= ~7'b0111111;
	if (cogs_inuse == 1) cogs_used <= ~7'b0000110;
	if (cogs_inuse == 2) cogs_used <= ~7'b1011011;
	if (cogs_inuse == 3) cogs_used <= ~7'b1001111;
	if (cogs_inuse == 4) cogs_used <= ~7'b1100110;
	if (cogs_inuse == 5) cogs_used <= ~7'b1101101;
	if (cogs_inuse == 6) cogs_used <= ~7'b1111101;
	if (cogs_inuse == 7) cogs_used <= ~7'b0000111;
	if (cogs_inuse == 8) cogs_used <= ~7'b1111111;

end


always @(*) begin;

		cog_status_leds <= (prop0_cog_ind) & (selected_prop == 0)
		| (prop1_cog_ind) & (selected_prop == 1)
		| (prop2_cog_ind) & (selected_prop == 2)
		| (prop3_cog_ind) & (selected_prop == 3)
		| (prop4_cog_ind) & (selected_prop == 4);
		
end

always @(*) begin;
		
		cogs_inuse <= cog_status_leds[0]
		+ cog_status_leds[1]
		+ cog_status_leds[2]
		+ cog_status_leds[3]
		+ cog_status_leds[4]
		+ cog_status_leds[5]
		+ cog_status_leds[6]
		+ cog_status_leds[7];

end

always @(*) begin;

	prop0_resn <= !(selected_prop == 0) | propplug_resn & pb_reset;
	prop0_rx <= !(selected_prop == 0) | propplug_rx;
	
	prop1_resn <= !(selected_prop == 1) | propplug_resn & pb_reset;
	prop1_rx <= !(selected_prop == 1) | propplug_rx;
	
	prop2_resn <= !(selected_prop == 2) | propplug_resn & pb_reset;
	prop2_rx <= !(selected_prop == 2) | propplug_rx;
	
	prop3_resn <= !(selected_prop == 3) | propplug_resn & pb_reset;
	prop3_rx <= !(selected_prop == 3) | propplug_rx;
	
	prop4_resn = !(selected_prop == 4) | propplug_resn & pb_reset;
	prop4_rx = !(selected_prop == 4) | propplug_rx;
	
	propplug_tx <= (!(selected_prop == 0) || prop0_tx)
	& (!(selected_prop == 1) || prop1_tx)
	& (!(selected_prop == 2) || prop2_tx)
	& (!(selected_prop == 3) || prop3_tx)
	& (!(selected_prop == 4) || prop4_tx);
	
end


endmodule

I'm having a few dramas with Quartus and that in combination with my long compile times doesn't help.
The problem I am having with Qaurtus is each time I add a new peripheral to a prop I seem to lose or
partially corrupt already proven pin assignments. This seems a bit random too. Running some simple
cog tests on each of the 40 cogs show that they are running Ok but the peripherals are not!
I know it's something I must be doing wrong but the $64K question is what? Anyhow still having heaps of fun

Cheers
Brian

to mess up some the pin assignments.

mindrobots · 2014-08-22 06:11

Brian,

Thank you for the details. Hopefully, I can have some quiet time with my DE2 this weekend (Haha!!) and sit down and try this. I'll certainly let you know if I break my Quartus (Ouch!) along the way!

It is a bit too much fun - I'm waiting for someone to come along and tell me it is illegal (or bad for me)!

pik33 · 2014-08-22 11:12

Assignments->settings->fitter->more settings->fitter aggressive routability optimizations->always

This - in my prop1v experiments - reduces compilation time several times

The Quartus fits the logic as it can, and then the router has a problem to connect all this and it can spend up to 15 minutes doing this.

Changing this setting reduces my compilation times under 10 minutes (1 prop circuit, AMD FX8320@4GHz)

pik33 · 2014-08-22 11:17

mindrobots wrote: »

It is a bit too much fun - I'm waiting for someone to come along and tell me it is illegal (or bad for me)!

It is bad for you - when you are working with Quartus, you don't eat and drink.

cgracey · 2014-08-22 12:31

pik33 wrote: »

It is bad for you - when you are working with Quartus, you don't eat and drink.

Ah, yes, I hope to benefit from the Quartus diet.

Quartus is a huge program. The several-minute wait times (and several steps to run) have a big divider effect on your productivity, because your mental cache is pretty thoroughly dumped by the time you get to try out your changes. I've always wanted to make a development tool for FPGAs that would compile, download, and execute your code in a few seconds, or less. Then, development would proceed 20x faster. I would be able to approach projects in a much less formal, more organic way, rather than have to mentally spool up and implement a whole concept before enduring the long waits and numerous steps to see the results. Of course, FPGA compilers are a lot more complicated than assemblers, so this may not be practical without some accommodations being made for each specific FPGA architecture, where little blocks get compiled for later routing, so that a top-down effort is not needed each time. The practical difficulty in doing this would be adapting the tool to every device it supports. Altera decided long ago to decouple a few big things to allow their tools to evolve without too much pulling and pushing. Anyway, simple and fast tools might allow FPGAs to gain the widespread use that microcontrollers have. FPGAs are still way more complicated to use than micros.

pik33 · 2014-08-24 11:27

The several-minute wait times (and several steps to run) have a big divider effect on your productivity, because your mental cache is pretty thoroughly dumped by the time you get to try out your changes.

Yes, it is, but things go better. New Quartus versions(12+) compiles several times faster. than these(8..9) which I started two years ago. Then, there are some settings which can shorten this time. The compilation time of my project with extended port B was over 20 minutes when original Propeller project compiles in about 4 minutes Then I found "Aggresive routability optimizattion" which, when set, shorten the compilation time of this project to 6..7 minutes.

The Quartus is a huge beast and there are many things to learn.

jazzed · 2014-08-24 15:48

cgracey wrote: »

Ah, yes, I hope to benefit from the Quartus diet.

Better be running regularly around the orchard and snacking lightly or that diet won't work.

ozpropdev · 2014-08-25 05:51

Update:
I've been running a few trials of 5 x P1V's and had some interesting results.
Apart from the HUGE compile times on my old PC (~!1Hr 20 Mins) the P1V clock speed seems to be an issue with these builds.
@140 Mhz 9 out of the 40 cogs either failed completely or were erratic.
@133 Mhz 3 out of the 40 cogs were erratic.
Trying 120 Mhz next. Compiling.........

Update: 120 MHz seems to have fixed erratic behaviour. All 40 cogs running nicely.

:)
Hope to post source and demo code in the next day or so.

ozpropdev · 2014-08-25 06:52

pik33 wrote: »

Assignments->settings->fitter->more settings->fitter aggressive routability optimizations->always

This - in my prop1v experiments - reduces compilation time several times

The Quartus fits the logic as it can, and then the router has a problem to connect all this and it can spend up to 15 minutes doing this.

Changing this setting reduces my compilation times under 10 minutes (1 prop circuit, AMD FX8320@4GHz)

I changed this setting in my Quartus 13.1 (32 bit) on Win 7.a couple of days ago.
It made no difference at all to my compile times.
I was hoping it would help, in my case it didn't

It was worth trying though, Thanks

pik33 · 2014-08-25 08:36

ozpropdev wrote: »

Update:
I've been running a few trials of 5 x P1V's and had some interesting results.
Apart from the HUGE compile times on my old PC (~!1Hr 20 Mins) the P1V clock speed seems to be an issue with these builds.
@140 Mhz 9 out of the 40 cogs either failed completely or were erratic.
@133 Mhz 3 out of the 40 cogs were erratic.
Trying 120 Mhz next. Compiling.........

Update: 120 MHz seems to have fixed erratic behaviour. All 40 cogs running nicely. :)
Hope to post source and demo code in the next day or so.

Yes, it seems 140 MHz P1v works, but it sometimes makes a mistake. Today I run this vga driver @ 140 MHz and the inttostr function couldn't strip all leading zeros from the resulting string. It returned strings like "00002" instead of simply "2"

Then I reduced the system clock to 120 MHz and it worked OK

I reduced it further to 106.5 MHz to get synchronization with the pixel clock.

How did you attach the LCD?

ozpropdev · 2014-08-25 21:17

Heres my current source and demo code.

5 x P1V propellers with 64 I/O pins running @ 120MHz. (Note: PortB not implemented in counters yet!)
The only other modification is the extraction of the DIRA/DIRB status to allow for tri-state control of additional
logic and interfaces. This assists in the propplug management. All five propellers can be programmed via
a single propplug. An additional propplug can be connected (see picture) for additional comms.

There are five spin programs, one for each propeller.
prop0.spin runs a lcd message demo. Lcd is mapped to PortB pins. Sends data out a second proplug too.
prop1.spin uses two 7 segment displays(HEX5&4) to display IR detector activity.
prop2.spin simply counts 0 to 9999 on 7 segment displays (HEX3..0)
prop3.spin shows a "cylon" style led pattern on red leds(7..0). SW(7..0) status pauses display.
prop4.spin also shows a "cylon" style led pattern on red leds(17.80). SW(17..8) status pauses display. (Test of INB)

To load each propeller simply select the propeller using KEY1. Current selected propeller is shown on HEX7 display.
KEY0 is a manual reset for the current selected propeller.
The HEX6 display shows the number of cogs used by the current selected propeller and the green leds show their individual status.

With 320 IO pins available for hooking up all the DE2 goodies it opns the door to lots of fun.

See spin code and schematic for pin assignments.

BTW. I'm curious on the compile times achieved on your faster PC's rather than my old "clunker"

Cheers
Brian

Edit: Apologies for the copped schematic. Quartus export seems to behave badly!

pik33 · 2014-08-25 23:20

Compiled with AMD FX8320@ 4.2 GHz - time is 31:32

ozpropdev · 2014-08-26 02:40

Thanks pik33. I definitely need a new machine!

Building 5 x P1V's in a DE2-115

Comments