Please check my circuit diagram - if it is feasible or not?

JaanDoh

Hello Propeller-Heads,

Coming from a programming background,
I'm finding it difficult when it comes to the electronics part of a propeller based project.
Well I'm trying to forward my learning,
I
wanted to use external RAM for the VGA buffer because the on board RAM is not enough.

The VGA graphics resolution would be 1280 x 720 (HD or HD Ready)
And I want to use 1 byte per pixel
That means I need 1280 x 720 = 921,600 Bytes

And before I start to write code for my project,
I would really appreciate if anyone can browse over my circuit layout and point out the mistakes or flaws.
It is my first design so please be gentle lol

I've opted for 2 x Alliance ASC4008 Ram to give me 1 Megabyte of ram for the video display buffer (1280 x 720 resolution)

What I have tried to do is use as few pins as possible for the address bus (on the basis that most times the data bytes read/written will be longer than the address bytes? Is this such a good idea?)

I know I need to put decoupling capacitors on, but not sure where and what size.
I think they need to be at the power supply and not sure if I need them on the memory chips?

I made the design using Easy EDA - I found it easy to use and I'm a complete beginner at electronic design.


Thanks

Jaan


Offsite document links:
Texas Instruments - http://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Alliance Memory - http://www.alliancememory.com/pdf/AS6C4008 feb 2007 with tsop 11.pdf

kwinn

First, this is going to be way too slow to drive a video display directly. Other than that, the only other possible problem I can see is having the same clock signal for SCK and RCK. Not sure what would end up in the output register when you are shifting the data and transferring it to the output register at the same time.

jmg

JaanDoh wrote: »

The VGA graphics resolution would be 1280 x 720 (HD or HD Ready)
...
I would really appreciate if anyone can browse over my circuit layout and point out the mistakes or flaws.

You need to first get a pencil and a calculator - check what clock speed you need to deliver 1280 x 720 pixels.
If the MHz values cannot be met, all other details are moot.

JaanDoh wrote: »

I've opted for 2 x Alliance ASC4008 Ram to give me 1 Megabyte of ram for the video display buffer (1280 x 720 resolution)

As a general rule, avoid two memories.
PCB traces get much longer, and routing is more complex, and performance is worse than 1 RAM.

JaanDoh wrote: »

What I have tried to do is use as few pins as possible for the address bus (on the basis that most times the data bytes read/written will be longer than the address bytes? Is this such a good idea?)

See other posts on here, where instead of HC595, which are very slow to load, they used loadable counters.
Loadable counters mean just a clock is needed, to scan the pixels once the address is set.

JaanDoh

kwinn wrote: »

First, this is going to be way too slow to drive a video display directly. Other than that, the only other possible problem I can see is having the same clock signal for SCK and RCK. Not sure what would end up in the output register when you are shifting the data and transferring it to the output register at the same time.

Hello and thank you for your help.

It's a bit soul destroying to find it will be too slow to drive the vga
But I'm learning along the way
So what can I do to speed it up?

As for tying the two clocks together...
I thought it would free up some pins as the documentation quoted:

The clocks can be tied together, in which case the shift register is one clock pulse ahead of the storage register

Thanks,


Jaan

kwinn

It is as JMG posted. A lot of data has to go out to the video display 60 times a second to produce a flicker free image. A 1280 x 720 needs to output 921,000 pixels 60 times per second, or 55,296,000 pixels per second, and on top of that there is the time required for vertical and horizontal sync. That requires high frequency counters and fast memory as well as careful board layout. Definitely not a project for someone new to electronics. If you need that kind of display I would suggest using a Pi Zero for the display and the propeller for the I/O controller. An awesome combination.

JaanDoh

jmg wrote: »

JaanDoh wrote: »

The VGA graphics resolution would be 1280 x 720 (HD or HD Ready)
...
I would really appreciate if anyone can browse over my circuit layout and point out the mistakes or flaws.

You need to first get a pencil and a calculator - check what clock speed you need to deliver 1280 x 720 pixels.
If the MHz values cannot be met, all other details are moot.

JaanDoh wrote: »

I've opted for 2 x Alliance ASC4008 Ram to give me 1 Megabyte of ram for the video display buffer (1280 x 720 resolution)

As a general rule, avoid two memories.
PCB traces get much longer, and routing is more complex, and performance is worse than 1 RAM.

JaanDoh wrote: »

What I have tried to do is use as few pins as possible for the address bus (on the basis that most times the data bytes read/written will be longer than the address bytes? Is this such a good idea?)

See other posts on here, where instead of HC595, which are very slow to load, they used loadable counters.
Loadable counters mean just a clock is needed, to scan the pixels once the address is set.

I saw this obex object - VGA 1280 x 1024
http://obex.parallax.com/object/646

And thought I would be okay with the slightly smaller resolution of 1280 x 720 that I opted for.
Being a beginner to the propeller and electronics I must assume the flaw is with my choice of HC595 decoder/multiplexer (or something like that)

I've taken on board what you said about using one RAM chip as opposed to more than one.

Now I'm off to look into loadable counters.


Thanks

Jaan

Phil Pilgrim (PhiPi)

For speed and reliable timing, you definitely need a crystal tied to XO and XI. Also, do not forget to add bypass caps to all your ICs (two on the 40-pin Prop).

-Phil

kwinn

Not saying this cannot be done, just that it is not easy. See this link for the timing. I think it might be possible for one cog to generate the pixel clock (74.2MHz), horizontal sync (45KHz), and vertical sync (60Hz) to drive the external counters. Then at least one other cog would be needed to update the video ram.

JaanDoh

kwinn wrote: »

It is as JMG posted. A lot of data has to go out to the video display 60 times a second to produce a flicker free image. A 1280 x 720 needs to output 921,000 pixels 60 times per second, or 55,296,000 pixels per second, and on top of that there is the time required for vertical and horizontal sync. That requires high frequency counters and fast memory as well as careful board layout. Definitely not a project for someone new to electronics. If you need that kind of display I would suggest using a Pi Zero for the display and the propeller for the I/O controller. An awesome combination.

Thank You,

I managed to find a Pi Zero at an acceptable price.


Jaan

JaanDoh

Phil Pilgrim (PhiPi) wrote: »

For speed and reliable timing, you definitely need a crystal tied to XO and XI. Also, do not forget to add bypass caps to all your ICs (two on the 40-pin Prop).

-Phil

Thank You,
I guess I should have stated that I have 5Mhz Crystal,

At the expense of seeming simple....
Where would I place the capacitors?
On the power lines?
Kind of from the positive to the negative?

Also note that I copy/pasted the wrong 5V value on the propeller when it should be 3.5


Thank You too for your help.


Jaan

JaanDoh

kwinn wrote: »

Not saying this cannot be done, just that it is not easy. See this link for the timing. I think it might be possible for one cog to generate the pixel clock (74.2MHz), horizontal sync (45KHz), and vertical sync (60Hz) to drive the external counters. Then at least one other cog would be needed to update the video ram.

Thank you for the display config timing link
I have saved it in my favourites.

I had intended to use 3 cogs for reading/displaying the video (as per the sample in the obex)
And one cog for writing to the video ram

I will still have the pi zero to fall back on if this fails.


Thanks


Jaan

ErNa

a prop is one thing for everything and in so far specialized things always are just better. The prop will help to understand the principles of video generation, you will come to limits very fast and so understand the limitations. After you evaluated the hardware concepts successfully, you will have learned a lot and be able to understand your problems and what the right tools to solve them are.
To learn hardware the problem you showed is to high a summit. ;-) If you MUST solve this problem, Rayman has a graphic extention board designed and he shows many solutions: http://www.rayslogic.com/propeller/Programming/Programming.htm Or a graphic controller based dvi board http://www.rayslogic.com/Propeller/Products/DviGraphics/DVI.htm

jmg

kwinn wrote: »

... I think it might be possible for one cog to generate the pixel clock (74.2MHz), horizontal sync (45KHz), and vertical sync (60Hz) to drive the external counters...

Can the Prop generate 74.2MHz on a Pin ? I thought it was limited to up to SysClk/2 /

Probably the best new memory to look at for Video, is the HyperRAM now stocked.
http://www.digikey.com/product-search/en?keywords=HyperRAM

These are DDR, so they need only 37.1MHz toggle for a 74.2MHz pixel rate.
The P1 many need some crystal choice to lower jitter on the PLL side, should be easy to check.

Probably not for novices, until someone proves the details, but these parts have a simple Clocked-streaming output, and the circuit reduces right down to 3 key parts : {P1 + HyperRAM + SimpleOctalBuffer}

Octal buffer drives the VGA cable, and gives a blanking during flyback ability.

Simplest playback is to include Sync=black in the RAM, and then just clock continually.
( with 8M Bytes in these parts, there is RAM to spare...)

Video-write has the choice of Flyback-only for small changes, or full time for large screen updates.

There are some boards in the pipeline with P1 & HyperRAM, so reports should be in soon on how this all works.

Latest data says this, which is good news as it suggests > 1024 bytes(1 Row) can stream gap-less.

" When configured in linear burst mode, the device will automatically fetch the
next sequential row from the memory array to support a continuous linear burst. Simultaneously accessing
the next row in the array while the read or write data transfer is in progress, allows for a linear sequential burst
operation that can provide a sustained data rate of 333 MB/s (1 byte (8 bit data bus) * 2 (data clock edges) *
166 MHz = 333 MB/s)."

Phil Pilgrim (PhiPi)

jmg wrote:

Can the Prop generate 74.2MHz on a Pin ? I thought it was limited to up to SysClk/2

Absolutely! That and more, using the counters in PLL mode.

-Phil

jmg

Phil Pilgrim (PhiPi) wrote: »

Absolutely! That and more, using the counters in PLL mode.

Good to know.
Looking at the specs, and my comment The P1 many need some crystal choice to lower jitter on the PLL side, should be easy to check
I think that is more important than for just display jitter, as the P1 needs to flip between Read(Fast PLL Clocked) and Write(Slower PLL, or SW Clk), and wants to avoid runt pulses when doing that.
That likely needs a close integer lock between P1 SysCLK and PixelClock.

JaanDoh

Thank You all for your help,

I'm obviously in over my head here.

Well it's back to the drawing board for me.