Port B first run
pik33
Posts: 2,366
Edit
Added the project source here. Warning - not cleaned! As it is now.
The project was made with Quartus 13.1 for DE2-115 board.
To use: open proptest project, compile, program.
SW0 has to be ON before programming the Propeller.
The Propeller has to be programmed via RS232 connector in DE2-115. I program it by real RS232 port - I don't know if usb-rs232 dongles can work.
If you want to use a PropPlug you have to change UART_xxx pins to GPIO[yy] pins, so P30, P31 and RESn will be connected to GPIO pins used by PropPlug instead or RS232. I didn'd do this because I am still waiting for a PropPlug and cannot test this configuration
When I get a PropPlug I will make my projects compatible with both programming methods.
In Propeller Tools open the portb.spin and run. Connect a VGA monitor. You should see "Port B demo running in cog 3" text.
or
copy cog.v, prop.tdf (to top.tdf), dig.inc and dig.v to your default Propeller Quartus project and use it as before, having 145 MHz speed and portb enabled.
Please test if it compiles and works
At now I have working PortB output
It needs to make changes in some files. dig.inc, top.tdf dig.v and cog.v.
Connected outb[7..0] to ledr[17..10] and run this:
It works
Now these are pure outputs only. I have to locate and add code to get inputs, too, and I still don't know what to do with counters etc.
Another difference is: when I connectd leds to Port A, they are on after the propeller starts. So, I had to add
to make leds LEDR[7..0] which are are connected to P16..P23 in my project dark. LEDR[17..10], which I connected to Port B [7..0] are dark when the Propeller starts.
Maybe it has something to do with inputs still not connected.
Added the project source here. Warning - not cleaned! As it is now.
The project was made with Quartus 13.1 for DE2-115 board.
To use: open proptest project, compile, program.
SW0 has to be ON before programming the Propeller.
The Propeller has to be programmed via RS232 connector in DE2-115. I program it by real RS232 port - I don't know if usb-rs232 dongles can work.
If you want to use a PropPlug you have to change UART_xxx pins to GPIO[yy] pins, so P30, P31 and RESn will be connected to GPIO pins used by PropPlug instead or RS232. I didn'd do this because I am still waiting for a PropPlug and cannot test this configuration
When I get a PropPlug I will make my projects compatible with both programming methods.
In Propeller Tools open the portb.spin and run. Connect a VGA monitor. You should see "Port B demo running in cog 3" text.
or
copy cog.v, prop.tdf (to top.tdf), dig.inc and dig.v to your default Propeller Quartus project and use it as before, having 145 MHz speed and portb enabled.
Please test if it compiles and works
At now I have working PortB output
It needs to make changes in some files. dig.inc, top.tdf dig.v and cog.v.
//In dig.inc line 24:
RETURNS (cfg[7..0], pin_out[31..0], pin_dir[31..0], pin_outb[31..0], pin_dirb[31..0], cog_led[7..0]);
--------------------------------------------------
//In prop.tdf (was top.pdf in original version) added
pinb [31..0] : tri;
//then
pinb[].in = core.pin_outb[];
pinb[].oe = core.pin_dirb[];
iob[] = pinb[].out;
--------------------------------------------------
In dig.v added:
output [31:0] pin_outb, // pin state outputs
output [31:0] pin_dirb, // pin direction outputs
//then in "cogs" segment
wire [7:0] [31:0] outxb;
wire [7:0] [31:0] dirxb;
//and when generating cogs:
.pinb_out (outxb[i]),
.pinb_dir (dirxb[i])
// then pin sections
assign pin_outb = outxb[7] | outxb[6] | outxb[5] | outxb[4] | outxb[3] | outxb[2] | outxb[1] | outxb[0];
assign pin_dirb = dirxb[7] | dirxb[6] | dirxb[5] | dirxb[4] | dirxb[3] | dirxb[2] | dirxb[1] | dirxb[0];
------------------------
// now cog.v
input [31:0] pinb_in, // pins
output [31:0] pinb_out,
output [31:0] pinb_dir
//then
wire setoutb = wio && i[dl+3:dl] == 4'h5;
wire setdirb = wio && i[dl+3:dl] == 4'h7;
//then
always @(posedge clk_cog or negedge ena)
if (!ena)
outb <= 32'b0;
else if (setoutb)
outb <= alu_r;
always @(posedge clk_cog or negedge ena)
if (!ena)
dirb <= 32'b0;
else if (setdirb)
dirb <= alu_r;
// and at the end
assign pinb_out = (outb & dirb);
assign pinb_dir = dirb;
Connected outb[7..0] to ledr[17..10] and run this:
CON _clkmode = xtal1+pll16x _clkfreq = 145_000_000 pub demo dira:=$00FF_0000 outa:=0 dirb:=$0000_00FF outb:=0 repeat outb[7]:=0 outb[0]:=1 waitcnt(cnt+clkfreq>>4) outb[0]:=0 outb[1]:=1 waitcnt(cnt+clkfreq>>4) outb[1]:=0 outb[2]:=1 waitcnt(cnt+clkfreq>>4) outb[2]:=0 outb[3]:=1 waitcnt(cnt+clkfreq>>4) outb[3]:=0 outb[4]:=1 waitcnt(cnt+clkfreq>>4) outb[4]:=0 outb[5]:=1 waitcnt(cnt+clkfreq>>4) outb[5]:=0 outb[6]:=1 waitcnt(cnt+clkfreq>>4) outb[6]:=0 outb[7]:=1 waitcnt(cnt+clkfreq>>4)
It works
Now these are pure outputs only. I have to locate and add code to get inputs, too, and I still don't know what to do with counters etc.
Another difference is: when I connectd leds to Port A, they are on after the propeller starts. So, I had to add
dira:=$00FF_0000 outa:=0
to make leds LEDR[7..0] which are are connected to P16..P23 in my project dark. LEDR[17..10], which I connected to Port B [7..0] are dark when the Propeller starts.
Maybe it has something to do with inputs still not connected.
Comments
I've been stuck with 4 errors in Quartus and your post alerted me to the dig.inc file.
I changed that and quartus compiled my nano code first try!
I'm back in business - P1 on nano with 64 I/O!
Programming now.....
Added:
// in prop.tdf core.pin_inb[] = iob[]; //in dig.inc FUNCTION dig (nres, clk_cog, clk_pll, pin_in[31..0], pin_inb[31..0]) //dig.inc //in dig.v .pinb_in (pin_inb), // in cog.v input [31:0] pinb_in, // pins - : i[sh:sl] == 9'h1F3 ? pinb_inThis needs to be tested and cleaned now
Just got back in front of it all, don't know where you get the time but I'm compiling with those changes now, thanks!
subdesign top ( clock_50 : input; -- clock input inp_resn : input; -- reset pin io [31..0] : bidir; -- i/o pins iob [31..0] : bidir; -- i/o B pins ledg [7..0] : output; -- cog leds )But these are the errors:Error (287084): Symbolic name "pin_inb" is used but not defined as a group
Error (287097): Left of Boolean equation cannot contain text "pin_inb"
Error (287114): Groups cannot be assigned to nodes
Error: Quartus II 64-Bit Analysis & Synthesis was unsuccessful. 3 errors, 1 warning
Error: Peak virtual memory: 725 megabytes
Error: Processing ended: Tue Aug 12 23:42:03 2014
Error: Elapsed time: 00:00:01
Error: Total CPU time (on all processors): 00:00:01
Error (293001): Quartus II Full Compilation was unsuccessful. 5 errors, 1 warning
Please bear with me, I'm trying to sort this out myself but my Verilog skills are still only a few hours old
EDIT: found the earlier post but also included in cog.v prior to always section
reg [31:0] outb;
reg [31:0] dirb;
That right?
Does the last line of your last post
: i[sh:sl] == 9'h1F3 ? pinb_in
belong in cog.v under //source
as part of wire[31:0] sx...?
I think pik has given himself a well deserved vodka break...this is where I put it:
wire [31:0] sx = i[im] ? {23'b0, i[sh:sl]} : i[sh:sl] == 9'h1F0 ? {16'b0, ptr[27:14], 2'b0} : i[sh:sl] == 9'h1F1 ? cnt : i[sh:sl] == 9'h1F2 ? pin_in : i[sh:sl] == 9'h1F3 ? pinb_in // PINB : i[sh:sl] == 9'h1FC ? phsa[31:0] : i[sh:sl] == 9'h1FD ? phsb[31:0] : sy;Thank you for getting this rolling. This alone makes a huge leap forward for the P1V. Hopefully with my ZERO Verilog skills I can figure out how to implement this on my BEMicro CV when it gets here.
One of the problems with the block approach is that you need the sources. Obviously, that won't be available for the P2.
I was wondering if anything like the block implantation is possible for .jic type files... or if they (.jic) could be modified somehow to expose just enough to allow a block-like implementation.
Not sure, I'm too wet behind the ears yet, but I'm sure I've picked up another typo too:
// in prop.tdf core.pin_inb[] = iob[]; Instead: -- port B core.pin_in[] = iob[]; -- must be core.pin_in[] not inb[] ???? pinb[].in = core.pin_out[]; pinb[].oe = core.pin_dir[]; iob[] = pin[].out;I did get it to compile but I'm making some other changes and I will post the zip when it looks good.
I needed working PortB to add a sound chip. Maybe tomorrow the DE115 will give some sound. I hope the SD card will be easy, simply connecting P0..P4 to SD slot on DE2-115
Great work. Looking forward to it!
FedEx tracking says my BE MICRO CV's will be delivered today by 5pm... I should download the latest Quartus Web Edition.
Yes, I had found that after I fixed dig.inc as there was a typo as now I see the relationship. I need to sleep although I have learned a lot just patching this, so that's good.
clk0_multiply_by = 28, clk0_divide_by = 5);28 will give 140 MHz on the Propeller... 30 will be 150.. etc... In my experiments this is still the wall. I got it running @ 155 MHz but then there was errors (bad colors displayed on the monitor). Still have to learn the timing tool to know how to apply the patch proposed by Chip - he thinks the cog can run then over 200 MHz.
PortC will not be easy. We can of course give it an addresses like 1ED..1EF but then there is no PortC in Spin and we will have lost compatibility.
Good grief Charlie Brown.....of all the dunderhead mistakes we make late at night.
Now it's compiling nicely, still takes just under 10 mins though.
I have some urgent work to finish - I am sneaking peeks at the forum while working on other stuff - but hopefully I can download the latest Quartus to this box today, and compile tonight
Compile times should be pretty good on this box, but I may have to upgrade the memory (8 core / 4Ghz, but only 8GB of ram) and switch to an SSD.
EDIT: I don't see where we can assign these pins to the physical pins, it seems IOB[0] ended up here: Which seems to be the SDRAM row address strobe??
But I have 32-channel 8-bit PWM running at 13.45kHz, nice. Being table based I can drop the resolution and increase the frequency too.
The Quartus connected it where it wants to, into random places changing from compilation to compilation, until you connect it to your desired pins
Peter, in Quartus go to the Assignment menu then choose Pin Planner. You should see the I/Os listed - just enter the appropriate pin designations into the Location column of the grid
Good progress.
Counter mapping to 64io should be possible using spare bits waiting in CTRx.
It's probably a good idea to split Video into a conditional, for those smaller FPGAs it may save significant logic to not include that.
The next logical thing to overlay on Counters and the other Spare Bits in CTRx, would be ADDING SERIAL support.
(but this needs to NOT break any counter operation)
Some ideas on this :
It could use the Counter PIN-Map MUX to save Logic, but means you have Counters OR Serial, and counters can be useful to generate some strobe signals.
It may be one Serial and One counter is enough ?
The MSB could flag a write to SER config, (allows 31b of Serial Config) and READ would need to merge selected CTR and SER bits.
Probably not much code Reads CTRx now ?
The simplest serial design would be ADC_SPI_RX.
That generates a CLK (can be continuous, under some CLK-DIV) and a CS
(of some user-set width, typically repeats 16 Clks).
More complex (dual, fast) ADCs need a SEL pin, eg toggling every 16c.
Perhaps that can be done with CTR ?
When enabled, SERx would make READ of a counter register Serial read (PHSx?)
Those low-logic-cost additions, would allow fast ADC support with invisible background streaming, to to 40/48+MHz.
Update:
If we go with my suggested latter approach we can always still use the C flag to select between A/B ports if dynamic port selection is required using this code to emulate the original behaviour (at the expense of one added instruction cycle/space).
Yes it would be great to get the long discussed reverse WAITVID for serial data using "WAITVID d,s WZ" for example. Maybe it could automatically use the counter(s) to assign the data/clock pins and clock rate on the nominated pins associated with the counter(s). Two counters in a COG gives you clock rate, and up to 4 defined pins (perfect for four pin SPI). I noticed there is a spare top bit of the CTRA/CTRB register which could be useful here to extend the counter mode for potential serial transfers and reverse WAITVID (same goes for VCFG by the way). A bidirectional transfer would then be possible, with the D argument receiving input data and S argument used for writing output data, and the instruction blocking until completion (like video based WAITVID already does today). Different WC/WZ combinations could also possibly be used to choose to not block and just poll. Lots of design possibilities there. I'm sure plenty of people will want this capability.
Having separate inb and outb is simpy wasting an address space We can write to the register to set the output and read the same address to get the input. We have 6 registers: ina,outa,dira, inb,outb,dirb. Let them be inouta, inoutb, inoutc, dira, dirb, dirc.
This of course breaks compatiblility.