Through D0 - D15 with the P8X32A when the ADV7123 BLANK pin is set to low.
Datasheet ADV7123:
The BLANK signal is latched on the rising edge of CLOCK.
While BLANK is a logical zero, the R0–R9, G0–G9 and R0–R9 pixel inputs are ignored.
When the P8X32A has ended his ram data transmission i set his output pins to low and the ADV7123 BLANK pin to high.
Can you draw up all the connections between the data pins, the propeller and the rest of the ram control pins?
The most pins are now connected.
SDRAM BA0, BA1, addresslines and datalines, ADV7123 BLANK are now controlled through four 74HC753. (Silverado_2_3.pdf )
The rest is still in progress !
Next step is to make the data bus between the MCU and the SDRAM bidirectional with two more 74HC573.
It's later the function of the bus driver programming to handle the bidirectional data transfer.
Can the CLK signal be created with a DS1077 or DS1085L ?
You could try, but because some timing comes from the Prop, I think the clocks need to be phase stable.
I would start with a common CLK and easy ratios first, then get more adventurous later...
But, but how i must connect the 1G57 with the 74LV174 ?
And the 74LV174 with the P8X32A ?
Because the Prop pins may not be fully SDRAM clk sync'd, and to allow some PLL possibilities, you wire the '174 as a clock domain edge system - ie simply two series D FF. XNOR is LOW on <>
eg
`1G57 is a OR (not) form, so with Pin1=H, PinC is Low for Low on OP, so that wires to CAS_ : SDRAM_CAS_ -> U17.OR.C
Pin A is LOW to disable WR_, (L = read or reset), so it would wire as
PropPin(WR_RDn) -> 175.D4
174.Q4 -> U17.OR.(!)A
SDRAM.CE_ could go to Prop, but there is a spare FF, and it keeps all SDRAM clk sync'd to do
Then
!Reset Signal ( or Prop Pin with pullup) -> 174.MRn , forces all Qn LOW when LOW.
SDRAM actions all commands on _/= so the Qn all need to change on SDRAM =\_, which means either generate CLK, !CLK or add an inverter
to drive 174.clk -> NOT(SDRAM.CLK)
with this, the active signals are now all 1 SDRAM clock wide, and are created from an EDGE of a pop pin.
So the actual Prop speed is less important, but it still decides when to write during flyback, and exactly when to start the
Pixel Burst Read, on each line, and when to terminate. (with some trailing blank pixels, Terminate timing can be relaxed)
The Prop also manages the Sync & Blank timing.
With a 1024 Full page, and read (scan) only, a RAS update for a new row is needed, then the Start Burst Read Command, and scan-us later, Terminate Read.
Writes needs a Wr,RAS and Wr,CAS pair, per byte written, so a only a few writes will optionally fit into Line blanking, and a larger block will fit into Frame blanking.
For the Load SDRAM Mode register, two prop pins must change at the same time, in all other cases, only one of RAS_ or CAS- is strobed.
I like the quite similar (superset) SiLabs SI5351A-B-GT MSOP10, it's a little more complex to load, but still i2c, and it can create TWO outputs.
Digikey show SI5351A-B-GT 1 : $1.34
Edit: Note that the Prop has a PLL mode in the Counter Block.
Exploring the NCO+PLL idea, (CTRMODE=%00011) and trying to find a practical crystal.
You can buy 25.175MHz Xtal/Osc Modules, but that needs /5 to hit the Prop sweet spot.
Not ideal. but it would give a simple starting point for testing, before PLLs were tried.
There may be a solution point at 4.9152MHz, which is a common crystal value
This gives a Prop CLK of 78.6432Mhz, close to 80MHz, and then the NCO can divide that by ~12.5, for a
PLL.Ref of 6.291456MHz, PLLx16 is then 100.663296, which can select /4 to give 25.165824MHz (as CLK, !CLK if needed) which should be near enough.
There is phase jitter on the VCO, but it is fast, at 3.145728MHz
CLK out is (4.9152*16)/(2^32/round(2^32/12.5))*16/4 = 25.1658240234375 MHz
A higher jitter solution of /12.7, gives 25.196850MHz from 5.000MHz
Might be worth a try, once stable Xtal-based scan is working
In a later project version could the SDRAM controlled through a SDRAM Controller, programmed in a CPLD.
Perhaps with a XC9572XL CPLD TQFP100 (72 free user I/O pins), if it had enough macrocells for it !
Should be possible to transform the SRAM-Driver into a SDRAM-Driver.
MT48LC32M16A2:
One 640X480X16 picture fits 29 times into one ram bank, there are 4 and this makes 116 pictures.
Needed are 2 640X480X16 bits ram regions for double buffering.
The rest are for graphic data like sprites and background tiles..
If every sprite and background tile has a 16X16 pixel size then they can be copied with only one 16X16 array.
Greater sprites could be displayed through sprite attachment.
For the background can be used 40X30 tiles.
Each sprite or background tile can have 256 different colors from 65536 possible !
1 pixel color = 16 bit = RRRRRGGGGGGBBBBB
In a later project version could the SDRAM controlled through a SDRAM Controller, programmed in a CPLD.
Perhaps with a XC9572XL CPLD TQFP100 (72 free user I/O pins), if it had enough macrocells for it !
If you were choosing a 100 pin CPLD, I'd use the Lattice MachXO2 series Lower power, and has RAM.
MT48LC32M16A2:
One 640X480X16 picture fits 29 times into one ram bank, there are 4 and this makes 116 pictures.
Keep in mind not all of a SDRAM will be practically usable.
Only those rows actively refreshed will be non volatile, and adding extra refresh will trade-off write bandwidth.
It's a little unclear what auto/multiple refresh combination exist.
The special case of RAS=CAS=WRN=LLL loads the Mode Register, which I think needs Write Burst Mode=Single Location Access, and Burst Length = Full Page and Burst Type=Sequential
Expanding on this, Random writes would use
Write Burst Mode=Single Location Access
but there may be good speed gains in a function that changes this bit, to allow
Write Burst Mode = 0 -> Programmed Burst Length
In that mode, a Value set on IO lines will page-burst-write until stopped, which would give faster fills & erase to EOL, ClrScreen ops.
- ie a single frame, effectively flipped to write instead of read, would be enough to ClrScreen (or N lines) to a common BG colour.
Add: For systems that need fastest whole-RAM update, a design that uses two COGs could be the most flexible, One COG would do Sync (and could have spare resource for (eg) UART), and one COG could purely do Sync'd Memory - that would allow Screen Blank, and 100% write bandwidth
i have done the wiring between MCU, SDRAM, 74LVC1G57GW and 74LV174.
Please take a look a the schematic. It would be nice if you control the wiring !
That looks how I would wire it, but you have no driver yet on the 174.CP line ?
For first tests, a 25.175Mhz Osc Module or a 1GX04+25.175Mhz xtal, and a /5 to the Prop could give a solid timebase.
Since there is already a 174 on the BOM, you can use another 174 as a /5 Johnson counter ( 5 FF + inverter + reset )
It may be possible to remove this later.
I'm a bit confused about how the timing works. Once it starts sending out pixels, I don't think that timing is critical and whether it is 25.175 or 25 or 26Mhz may not matter so much as you can always adjust the screen width on the monitor manually.
But the phase of the clock is going to be very important. Whatever the clock speed is, once you get to the end of the line, the number of clock pulses has to be exactly the same before you start the next line.
I can't see how to do this. The propeller can't generate the pulses directly. Programmable counters? Divide the clock and use the edge of that divided clock as the start pulse?
VGA boards have been around a long time - how was this solved back in the 1990s?
I'm a bit confused about how the timing works. Once it starts sending out pixels, I don't think that timing is critical and whether it is 25.175 or 25 or 26Mhz may not matter so much as you can always adjust the screen width on the monitor manually.
True, but the 25.175 gives a 'known good' starting point.
But the phase of the clock is going to be very important. Whatever the clock speed is, once you get to the end of the line, the number of clock pulses has to be exactly the same before you start the next line.
I can't see how to do this. The propeller can't generate the pulses directly. Programmable counters? Divide the clock and use the edge of that divided clock as the start pulse?
VGA boards have been around a long time - how was this solved back in the 1990s?
They did not use SDRAM's then
I would start with 2 COGs, one to manage H & V sync, and the second COG to manage the few R/W to SDRAM, but able to do block writes during Frame Blanking, without worrying about also doing SYNC. (and you would fit more writes in Line Blanking too)
This should also make debug easier, as the raster will (always) be stable, just the image will need adjusting.
The 174+XNOR takes care of the pulse width, so it is only the precise timing of the edge that matters, and the Prop can do that easily.
At /5 you would probably want to use multiples of 16 (or 16N + PhaseFraction) in the Prop WAIT to give whole-pixel delays. (MOD 5 steps)
Running at /4, would multiples of 4, for exact pixels, and even 4N+PhaseFraction, if you wanted to move fractional pixels for Tsu/Th tests/tune.
/4 means a Clock of 100.7MHz ?
PhaseFraction (if needed) Depends on what the PLL phase alignment is in the Prop OscIN -> PLL -> PinDelays ?
The project use now 3 P8X32A. First the master, second the graphic wizard and third stereo sound output.
For the sound output i prefer SIDCOG.
a) You seem to show Sync from different Prop, it should just be a a separate COG in the SDRAM part.
b) Using a GX04 gives a good xtal choice, but the Prop CLK needs to be not a separate xtal. - the start-burst write pulses need to be stable on all scan lines, so you do not want frequency creep/beat effects.
Adding a /N would allow /5 for a start and maybe /4 if you want to try ~100MHz - many seem quite ok running 100MHz
- just pay a little more for a high precision Vcc, to remove any Min-vcc risks.
Adding a /N would allow /5 for a start and maybe /4 if you want to try
I think i don't understand it in detail !
You should avoid having both 25.175Mhz and 5Mhz crystals.
Easiest is to divide the 25.175 by 5 ( or 4) to give you a stable clock relationship - a 174 wired as a johnson counter would be a simple divider, using a part already used elsewhere.
Comments
Datasheet ADV7123:
The BLANK signal is latched on the rising edge of CLOCK.
While BLANK is a logical zero, the R0–R9, G0–G9 and R0–R9 pixel inputs are ignored.
When the P8X32A has ended his ram data transmission i set his output pins to low and the ADV7123 BLANK pin to high.
What about all the other ram control pins that are not connected on the schematic?
Can you draw up all the connections between the data pins, the propeller and the rest of the ram control pins?
The most pins are now connected.
SDRAM BA0, BA1, addresslines and datalines, ADV7123 BLANK are now controlled through four 74HC753. (Silverado_2_3.pdf )
The rest is still in progress !
Next step is to make the data bus between the MCU and the SDRAM bidirectional with two more 74HC573.
It's later the function of the bus driver programming to handle the bidirectional data transfer.
Can the CLK signal be created with a DS1077 or DS1085L ?
I think i have connected the 1G57 in the right way with the SDRAM.
http://forums.parallax.com/attachment.php?attachmentid=101805&d=1369418740
But, but how i must connect the 1G57 with the 74LV174 ?
And the 74LV174 with the P8X32A ?
Pixel clock freq = 25.175MHz
Horizontal
front porch = 635ns
sync pulse = 3.813us
back porch = 1.907us
Whole line = 31.77us
Vertical
front porch = 318us
sync pulse = 63.6us
back porch = 1.049ms
Whole frame = 16.683ms
I would start with a common CLK and easy ratios first, then get more adventurous later...
Because the Prop pins may not be fully SDRAM clk sync'd, and to allow some PLL possibilities, you wire the '174 as a clock domain edge system - ie simply two series D FF. XNOR is LOW on <>
eg
PropPin(CASe) -> 174.D0, 174.Q0 -> 174.D1
174.Q0 -> U16.XNOR.A
174.Q1 -> U16.XNOR.C [U16.XNOR.OP -> SDRAM.CAS_ ]
PropPin(RASe) -> 174.D2, 174.Q2 -> 174.D3
174.Q2 -> U17.XNOR.A
174.Q3 -> U17.XNOR.C [U17.XNOR.OP -> SDRAM.RAS_ ]
`1G57 is a OR (not) form, so with Pin1=H, PinC is Low for Low on OP, so that wires to CAS_ : SDRAM_CAS_ -> U17.OR.C
Pin A is LOW to disable WR_, (L = read or reset), so it would wire as
PropPin(WR_RDn) -> 175.D4
174.Q4 -> U17.OR.(!)A
SDRAM.CE_ could go to Prop, but there is a spare FF, and it keeps all SDRAM clk sync'd to do
PropPin(CEn) -> 174.D5, 174.Q5 -> U19.INV.A U19.op -> SDRAM.CE_
Then
!Reset Signal ( or Prop Pin with pullup) -> 174.MRn , forces all Qn LOW when LOW.
SDRAM actions all commands on _/= so the Qn all need to change on SDRAM =\_, which means either generate CLK, !CLK or add an inverter
to drive 174.clk -> NOT(SDRAM.CLK)
with this, the active signals are now all 1 SDRAM clock wide, and are created from an EDGE of a pop pin.
So the actual Prop speed is less important, but it still decides when to write during flyback, and exactly when to start the
Pixel Burst Read, on each line, and when to terminate. (with some trailing blank pixels, Terminate timing can be relaxed)
The Prop also manages the Sync & Blank timing.
With a 1024 Full page, and read (scan) only, a RAS update for a new row is needed, then the Start Burst Read Command, and scan-us later, Terminate Read.
Writes needs a Wr,RAS and Wr,CAS pair, per byte written, so a only a few writes will optionally fit into Line blanking, and a larger block will fit into Frame blanking.
For the Load SDRAM Mode register, two prop pins must change at the same time, in all other cases, only one of RAS_ or CAS- is strobed.
Can't find a CE pin on the MT48LC32M16A2, but it has a CS# and a CKE pin !
For what it is, that part seems expensive ?
I like the quite similar (superset) SiLabs SI5351A-B-GT MSOP10, it's a little more complex to load, but still i2c, and it can create TWO outputs.
Digikey show SI5351A-B-GT 1 : $1.34
Edit: Note that the Prop has a PLL mode in the Counter Block.
CTRMODE %00011
PLL differential APIN =PLLx BPIN= !PLLx
PLL Div covers
VCO
oops, yes CS# ~~ CE#, CS# is mainly used to avoid reset uncertainties.
You can buy 25.175MHz Xtal/Osc Modules, but that needs /5 to hit the Prop sweet spot.
Not ideal. but it would give a simple starting point for testing, before PLLs were tried.
There may be a solution point at 4.9152MHz, which is a common crystal value
This gives a Prop CLK of 78.6432Mhz, close to 80MHz, and then the NCO can divide that by ~12.5, for a
PLL.Ref of 6.291456MHz, PLLx16 is then 100.663296, which can select /4 to give 25.165824MHz (as CLK, !CLK if needed) which should be near enough.
There is phase jitter on the VCO, but it is fast, at 3.145728MHz
CLK out is (4.9152*16)/(2^32/round(2^32/12.5))*16/4 = 25.1658240234375 MHz
A higher jitter solution of /12.7, gives 25.196850MHz from 5.000MHz
Might be worth a try, once stable Xtal-based scan is working
Perhaps with a XC9572XL CPLD TQFP100 (72 free user I/O pins), if it had enough macrocells for it !
I purchase this board next time:
http://www.seeedstudio.com/depot/xc9572xl-cpld-development-board-v1b-p-799.html
http://dangerousprototypes.com/docs/Lulu:_Yet_another_logic_analyzer
http://dangerousprototypes.com/docs/Lulu:_Yet_another_logic_analyzer#SRAM_driver
Should be possible to transform the SRAM-Driver into a SDRAM-Driver.
MT48LC32M16A2:
One 640X480X16 picture fits 29 times into one ram bank, there are 4 and this makes 116 pictures.
Needed are 2 640X480X16 bits ram regions for double buffering.
The rest are for graphic data like sprites and background tiles..
If every sprite and background tile has a 16X16 pixel size then they can be copied with only one 16X16 array.
Greater sprites could be displayed through sprite attachment.
For the background can be used 40X30 tiles.
Each sprite or background tile can have 256 different colors from 65536 possible !
1 pixel color = 16 bit = RRRRRGGGGGGBBBBB
If you were choosing a 100 pin CPLD, I'd use the Lattice MachXO2 series Lower power, and has RAM.
Keep in mind not all of a SDRAM will be practically usable.
Only those rows actively refreshed will be non volatile, and adding extra refresh will trade-off write bandwidth.
It's a little unclear what auto/multiple refresh combination exist.
Expanding on this, Random writes would use
Write Burst Mode=Single Location Access
but there may be good speed gains in a function that changes this bit, to allow
Write Burst Mode = 0 -> Programmed Burst Length
In that mode, a Value set on IO lines will page-burst-write until stopped, which would give faster fills & erase to EOL, ClrScreen ops.
- ie a single frame, effectively flipped to write instead of read, would be enough to ClrScreen (or N lines) to a common BG colour.
Add: For systems that need fastest whole-RAM update, a design that uses two COGs could be the most flexible, One COG would do Sync (and could have spare resource for (eg) UART), and one COG could purely do Sync'd Memory - that would allow Screen Blank, and 100% write bandwidth
i have done the wiring between MCU, SDRAM, 74LVC1G57GW and 74LV174.
Please take a look a the schematic. It would be nice if you control the wiring !
PS: Updated Schematic, now with X-Tal Driver.
That looks how I would wire it, but you have no driver yet on the 174.CP line ?
For first tests, a 25.175Mhz Osc Module or a 1GX04+25.175Mhz xtal, and a /5 to the Prop could give a solid timebase.
Since there is already a 174 on the BOM, you can use another 174 as a /5 Johnson counter ( 5 FF + inverter + reset )
It may be possible to remove this later.
But the phase of the clock is going to be very important. Whatever the clock speed is, once you get to the end of the line, the number of clock pulses has to be exactly the same before you start the next line.
I can't see how to do this. The propeller can't generate the pulses directly. Programmable counters? Divide the clock and use the edge of that divided clock as the start pulse?
VGA boards have been around a long time - how was this solved back in the 1990s?
True, but the 25.175 gives a 'known good' starting point.
They did not use SDRAM's then
I would start with 2 COGs, one to manage H & V sync, and the second COG to manage the few R/W to SDRAM, but able to do block writes during Frame Blanking, without worrying about also doing SYNC. (and you would fit more writes in Line Blanking too)
This should also make debug easier, as the raster will (always) be stable, just the image will need adjusting.
The 174+XNOR takes care of the pulse width, so it is only the precise timing of the edge that matters, and the Prop can do that easily.
At /5 you would probably want to use multiples of 16 (or 16N + PhaseFraction) in the Prop WAIT to give whole-pixel delays. (MOD 5 steps)
Running at /4, would multiples of 4, for exact pixels, and even 4N+PhaseFraction, if you wanted to move fractional pixels for Tsu/Th tests/tune.
/4 means a Clock of 100.7MHz ?
PhaseFraction (if needed) Depends on what the PLL phase alignment is in the Prop OscIN -> PLL -> PinDelays ?
How ?
Incidentally i'am learning to use the Xilinx ISE Design Suit 14.5 WebPack License.
For future CPLD and FPGA programming.
Joystick adapters are connected for SEGA Genesis Megadrive Gamepads.
My first design for the I/O pcb (It's a DipTrace PCB file):
Joystick adapters are connected for SEGA Genesis Megadrive Gamepads.
I will do !
I'am now switching SDRAM BA0 and BA1 with a 74LVC1G57GW AND and XNOR combination.
ADV7123 SNYC through the now free 74HC573 pin.
The project use now 3 P8X32A. First the master, second the graphic wizard and third stereo sound output.
For the sound output i prefer SIDCOG.
Updated Silverado_1_alpha schematic, added DS1307 RTC.
a) You seem to show Sync from different Prop, it should just be a a separate COG in the SDRAM part.
b) Using a GX04 gives a good xtal choice, but the Prop CLK needs to be not a separate xtal. - the start-burst write pulses need to be stable on all scan lines, so you do not want frequency creep/beat effects.
Adding a /N would allow /5 for a start and maybe /4 if you want to try ~100MHz - many seem quite ok running 100MHz
- just pay a little more for a high precision Vcc, to remove any Min-vcc risks.
What it meaned with adding a /N ?
Can you describe it in a more easy way ?
How can i improve the Vcc supply ?
I'am personally don't know better parts !
It was on two pages, but I see both label the Prop U1, so your design may be 'or' morphing two drawings.
You should avoid having both 25.175Mhz and 5Mhz crystals.
Easiest is to divide the 25.175 by 5 ( or 4) to give you a stable clock relationship - a 174 wired as a johnson counter would be a simple divider, using a part already used elsewhere.