Hacking a P1v camera

rjo__

I am a flat out noobie at this. What I actually wanted to do was to take pik33's code and add a camera to it.
The problem is that I would end up having to seriously modify code that I seriously don't understand.
As a work around for my relative ignorance, I decided to take one of Terasic's camera samples for the DE2-115/D5M
and add a P1V to that. I first tried converting everything to a block design... and failed. Then I remembered,
Seairth's verilog conversion of the Top.tdf file to Verilog and then found Magnus's changes rolled into the Pipistrello project on github.

A few weeks ago, I tried to merge the changes into Terasic's project and failed... can't remember why.
This weekend I succeeded... almost. I did merge the two code bases and did get the P1V and camera working together, but
ran into issues, when I tried to convert to 4 Cogs, which I will describe at the end.

Because Terasic's code is protected, I can't publish it here, but I can describe it.

First I modified the Pipistrello De2-115 code to use CLOCK3_50 and to use pin assignments for Parallax's DE2-115 AddOn board..

After verifying that this worked. I then opened the Terasic project and removed any use of LEDG
and modified the pin assignments so that the Propeller would use the IO through Parallax's AddOn board for the
DE2-115. Then I dumped the rest of the P1V code into the main directory of the Terasic project.

Then I took the various segments of the github top.v file and merged them into the top file of the camera project.

This would not compile for two reasons... we need to change the settings for verilog to SystemVerilog...
and at ASSIGNEMTNS->Devices->pin settings-?dual purpose pins change the last setting (nCEO) to "use as regular i/o"

this compiled and I took the picture of it, which is attached.

However, I want to use a 4Cog variant...

So, I made all of the changes... which can be found in one of my posts and the P1V4cog worked fine, but the camera
didn't work so well... lots of noise. I then went back to a clean, working DE2=115/D5M/P1v and verified that it worked.
And began making the 4Cog changes to the files manually, one at a time... and right away, I ran into trouble.

In dig.v

When I change the generate routine at ling 95 from

for (i=0; i<8; i++)

to
for (i=0; i<4; i++)

I immediately ended up with NOISE in the vga output.

I decided to make all of the other changes required and come back to this last.

I reverted the above change and instead changed line 77 dig.v from

bus_sel <= {bus_sel[6:0], ~|bus_sel[6:0]};

to
bus_sel <= {bus_sel[2:0], ~|bus_sel[2:0]};

and
Changed line 166 of hub.v to

assign bus_ack = ed ? {4'b0,bus_sel[1:0], bus_sel[3:2]} : 8'b0;

no problem. The Prop works and the Camera works without noise... The P1v only uses 4 cogs and sees the expected gains in throughput for both Spin and PASM.

But... I am generating all 8 cogs... just blocking four of them at the hub... this consumes resources and most importantly for
experimentation, it takes the compile cycle from around five minutes back up to 8:22.

I assume that when I don't generate all of the cogs, wires are literally left hanging and are causing noise.
Am I missing something?

Thanks,

Rich

p.s.

Am I going to get sued?... I just noticed some of the stuff at the top of the demo files from Terasic... what I have done appears to violate the terms of use...
Have I violated Parallax's terms of use... since I am using P1v code that I can't post without getting sued?
What a morass.

pik33

These Terasic's files are open source and "free to use with Terasic's board" - I treat them as a part of the board. So if we use these files with DE2-115 board I think we don't violate any license.

My retromachine project uses a sdram controller which is available as source code on the DE2-115 CD. The license note says this is copyrighted by Altera and free to any use with Altera hardware. If this is something wrong with using this with P1V.. of course I can make my own thing based on this code (and remove some bugs it contain).

ozpropdev

Rich
Quartus is a fickle beast. Lots of hidden traps lurk beneath it's shiny UI.

To speed up compile times I too have reduced the number of cogs with mixed results.
Sometimes it doesn't seem to matter and others time chaos follows. it's a lottery !

One trap of particular note that caught me out for a couple of days was the compiler gets
confused when you reference a part/parts of a pin definition group without referencing the rest of the group.
For example, in one of experiments I wanted to use a couple of segments in one of the 7 segment displays
on the DE2. When my code compiled the segments I wanted to use lay dormant but two completely random
segments of two separate displays lit? This also affected other pin assignments to act strangely.
The solution in the end was to tie the unused segments to Vcc and "hey presto" everything started working!

Wrestling with Quartus and its many oddities can be quite tiring. I would be even more disappointed if
I had of handed over my hard earned CA$H to Altera for the subscription edition.

Cheers
Brian

pik33

ozpropdev wrote: »

Rich
but two completely random segments of two separate displays lit?
Brian

This is a typical symptom of I/O assignments error, and/or then Quartus auto-naming switched on.

Options->analysis and synthesis->Block Design Naming. Switch it to Quartus. or it can change GPIO[0] to GPIO0. Then it cannot find GPIO0 in pin definition, then it connects it to the random pin, for example LED or HEX. Then it lit.
If you have set this to Quartus, you always can make this kind of error manually with the same result.

ozpropdev

assign pik33 = thanks;

This is typical of the little things that frustrate me about Quartus.
Reminds me of (dare I say it) a PIC processor with some obscure switch buried in some register page somewhere.
The pin assignments names are directly from the DE2-115 CD and therefore assumed to be valid in format.
The default settings of Quartus seem to be the cause of a lot of headache.
Anyhow your suggestion resolved my issue.
Cheers
Brian

pik33

Making the retromachine was a good lesson in Quartus with random errors, obscure switches and some other strange things.
And Terasic software added to DEx boards can be extremely buggy.
The SD card driver cannot write to SD. After some investigation I found a write function. It looks like

int write(argument list) {
// todo
}

Then I cannot run the SDRAM using the verilog driver I found on the attached CD until I found the CS input is only declared but not connected to anything.

rjo__

You guys are great... I have a three year old attached to my hip right now. More later:)

ozpropdev

pik33 wrote: »

And Terasic software added to DEx boards can be extremely buggy.

int write(argument list) {
// todo
}

Oops! That is embarrassing and disappointing

rjo__

This is as far as I am going to take this. It works and there is communication between the P1V and the camera... but I want to be free to distribute my work and port it to other boards... such as Parallax's upcoming FPGA board. So, I'm starting over from scratch.