Since the new programm version has the retries all programmings works.
The old programm version without retries couldn't programm this CPLD ! Not once !
wow, that is s l o w, but I guess it works.
I quickly tried it, on a FT232R (seems to like ONLY that exact FTDI variant ) and it swallows a ATF1502BE SVF file, without stopping on signature fail ?
Currently spinning its wheels, and it seems some of the s l o w speed is due to many messages scrolling past ?
hehe, with nothing connected but the FT232R, it gives a final Complete - Programming Successful!
oops...
...resurrecting a long thread (sorry I haven't had the patience to trawl through every posting...)
I was wondering if anyone has tried driving VGA using a Prop 1, SDRAM, and '374 latch.
My plans are to control the SDRAM control lines (nCS/nRAS/nCAS/nWE/CE) using WAITVID
so the device can run at high speed, routing the data lines direct to the screen (TFT module with 16
bit RGB). The Prop pins driving the address lines also can be latched on '374 to allow data writes.
So far only experimenting with a 'scope and using either 40MHz or 80MHz CLK, and generating all the timings by
VSCL accounting (the idea is to handle buffered RLE spans during blanking time and decrement
a counter with the VSCL values until its time to re-sync for the next frame (using a DEN/DCLK TFT
interface there's no need for Vsync handling).
I've got some old DIMMs with MT48LC16M8A2's to harvest (or use in-situ with a DIMM socket?).
Any thoughts? Gotchas? I was thinking a 74LCX374 might be a fast enough latch (the nOE has to
be nippy for 80MHz in particular).
@Mark_T, looks like you have something very clever working there. Propeller plus fast memory is a great synergy - the prop does the control signals and the ram stores much bigger pictures. I need to study the code more to see what you are doing in detail but it looks very good.
@Mark_T, looks like you have something very clever working there. Propeller plus fast memory is a great synergy - the prop does the control signals and the ram stores much bigger pictures. I need to study the code more to see what you are doing in detail but it looks very good.
OK, a bit more description should it help. The current code isn't running the SDRAM anything like flat out
so I have the luxury of being able to update address bits via OUTA on every RAM clock cycle, at 20MHz
(or 25MHz with 6.25 crystal). Thus the output from waitvid is also at that rate and I can issue an SDRAM
opcode in lockstep with the instructions. Since waitvid only allows 4 colours each waitvid instruction is
limited to 3 possible RAM opcodes plus NOP, which isn't quite enough for a complete burst setup and recovery,
so a burst read or write is normally done with two waitvids, one to set it up running and the other to stop it
and recover.
SDRAM opcodes are basically coded by 3 signals, nCAS, nRAS and nWR, and the basic ones are
NOP
ACTIVE (latch row address, open row)
READ or WRITE (latch column address, start burst transfer)
BURST-TERM (stop current burst)
PRECHARGE (close a row, setup sense amps for next one)
(the others set the mode register and do auto-refresh cycles)
So the idiom for starting a transfer are
ACTIVE (row and bank addresses to OUTA)
READ (column and bank addresses to OUTA)
and stopping is
BURST-TERM
PRECHARGE (bank address to OUTA)
The timing of waitvid means that the first "pixel" output is just before the next "mov OUTA, ..."
instruction, so this will be a NOP rather than ACTIVE, the typical sequence being
NOP, ACTIVE, READ (or WRITE), with the code doing
waitvid ..., ...
mov OUTA, highaddr ' in time for ACTIVE
mov OUTA, lowaddr ' in time for READ
To run at a higher RAM clock rate all that should be needed is to insert NOPs into
the stream to space out the opcodes to synchronize with the "mov OUTA" instructions
that setup addresses. In fact the timing constraints mean that at higher clock speeds
there need to be some NOPs anyway between ACTIVE and READ, between BURST-TERM
and PRECHARGE and between PRECHARGE and subsequent ACTIVE or AUTO-REFRESH.
Running at 80MHz (or 100 with 6.25 crystal) should just mean adding 3 NOPs between various
codes in the waitvid pixel data (and more careful attention to signal layout and termination).
Since waitvid can drive 8 signals, and only 3 (or 4 including clock-enable) are needed for the
SDRAM opcode, the others can be used for other uses (DEN for the screen, latch enable for
writing, DQM line to the SDRAM - the latter enables masked writes which make character
generation much faster.
I'm exclusively using page-mode bursts for read and write, but you can setup 1, 2, 4 or 8 byte
bursts too (which support automatic PRECHARGE).
Comments
Nice find, and some interesting comments on yields in 9500 series devices.
How long does pgm of the PLDs you have tried take, and how much does it vary, with the retries roulette ?
I might try that with an ATF15xx series device.
Since the new programm version has the retries all programmings works.
The old programm version without retries couldn't programm this CPLD ! Not once !
wow, that is s l o w, but I guess it works.
I quickly tried it, on a FT232R (seems to like ONLY that exact FTDI variant ) and it swallows a ATF1502BE SVF file, without stopping on signature fail ?
Currently spinning its wheels, and it seems some of the s l o w speed is due to many messages scrolling past ?
hehe, with nothing connected but the FT232R, it gives a final
Complete - Programming Successful!
oops...
Later i will try to programm a FPGA with this programm !
At those speeds, you might want to pass, and use some smarter hardware ??
The FT232H series have better JTAG support - if you can find SW to drive them.
Lattice tools have FT2232H devices on their breakout boards, so I'd suggest the MachXO2 series.
There are two versions available from the ADV7123.
A 240MHz and a 330MHz version, i think i use the 330MHz version.
I have found another 512 MBit SDRAM part, the IS42S16320B-7TLI.
http://uk.farnell.com/integrated-silicon-solution-issi/is42s16320b-7tli/sdram-ind-32m-x-16-3v-54tsop2/dp/1869963?Ntt=IS42S16320B-7TLI
But it looks expensive:
29,42 €
I was wondering if anyone has tried driving VGA using a Prop 1, SDRAM, and '374 latch.
My plans are to control the SDRAM control lines (nCS/nRAS/nCAS/nWE/CE) using WAITVID
so the device can run at high speed, routing the data lines direct to the screen (TFT module with 16
bit RGB). The Prop pins driving the address lines also can be latched on '374 to allow data writes.
So far only experimenting with a 'scope and using either 40MHz or 80MHz CLK, and generating all the timings by
VSCL accounting (the idea is to handle buffered RLE spans during blanking time and decrement
a counter with the VSCL values until its time to re-sync for the next frame (using a DEN/DCLK TFT
interface there's no need for Vsync handling).
I've got some old DIMMs with MT48LC16M8A2's to harvest (or use in-situ with a DIMM socket?).
Any thoughts? Gotchas? I was thinking a 74LCX374 might be a fast enough latch (the nOE has to
be nippy for 80MHz in particular).
Check out the Projects section: http://forums.parallax.com/showthread.php/150407-Video-graphics-controller-using-Propeller-to-control-SDRAM
I have meanwhile purchased three MT48LC32M16A2 64 MByte SDRAM IC's for my Silverado Project.
In future i use two of them in my project.
One for written new graphics data into it and a second for grafics data streaming to the video dac.
Then memory ic change for double buffering.
OK, a bit more description should it help. The current code isn't running the SDRAM anything like flat out
so I have the luxury of being able to update address bits via OUTA on every RAM clock cycle, at 20MHz
(or 25MHz with 6.25 crystal). Thus the output from waitvid is also at that rate and I can issue an SDRAM
opcode in lockstep with the instructions. Since waitvid only allows 4 colours each waitvid instruction is
limited to 3 possible RAM opcodes plus NOP, which isn't quite enough for a complete burst setup and recovery,
so a burst read or write is normally done with two waitvids, one to set it up running and the other to stop it
and recover.
SDRAM opcodes are basically coded by 3 signals, nCAS, nRAS and nWR, and the basic ones are
NOP
ACTIVE (latch row address, open row)
READ or WRITE (latch column address, start burst transfer)
BURST-TERM (stop current burst)
PRECHARGE (close a row, setup sense amps for next one)
(the others set the mode register and do auto-refresh cycles)
So the idiom for starting a transfer are
ACTIVE (row and bank addresses to OUTA)
READ (column and bank addresses to OUTA)
and stopping is
BURST-TERM
PRECHARGE (bank address to OUTA)
The timing of waitvid means that the first "pixel" output is just before the next "mov OUTA, ..."
instruction, so this will be a NOP rather than ACTIVE, the typical sequence being
NOP, ACTIVE, READ (or WRITE), with the code doing
waitvid ..., ... mov OUTA, highaddr ' in time for ACTIVE mov OUTA, lowaddr ' in time for READTo run at a higher RAM clock rate all that should be needed is to insert NOPs into
the stream to space out the opcodes to synchronize with the "mov OUTA" instructions
that setup addresses. In fact the timing constraints mean that at higher clock speeds
there need to be some NOPs anyway between ACTIVE and READ, between BURST-TERM
and PRECHARGE and between PRECHARGE and subsequent ACTIVE or AUTO-REFRESH.
Running at 80MHz (or 100 with 6.25 crystal) should just mean adding 3 NOPs between various
codes in the waitvid pixel data (and more careful attention to signal layout and termination).
Since waitvid can drive 8 signals, and only 3 (or 4 including clock-enable) are needed for the
SDRAM opcode, the others can be used for other uses (DEN for the screen, latch enable for
writing, DQM line to the SDRAM - the latter enables masked writes which make character
generation much faster.
I'm exclusively using page-mode bursts for read and write, but you can setup 1, 2, 4 or 8 byte
bursts too (which support automatic PRECHARGE).