As an aside, Eagle PCB seems to have library parts for Xilinx, Altera and Lattice. Most are tiny pin spacings/ball grid array but there are some PLCC packages and that means we could think about making our own boards too.
@Dr_Acula
Thanks for such a comprehensive reply.
Ok I am well out of my depth and will wait and see how things go.
It seems DigiAsic and wayengineer have a lot of stuff... http://stores.ebay.com/wayengineer/category2370586015-/_i.html?_fsub=2370586015
But the part numbers are just that, numbers - to me, they mean nothing without doing lots of research, and that is out of the question at the moment.
I can see that when your interest is piqued you are like a dog with a rat, you won't let it go until you've devoured all you can find.
I will watch this thread with interest.
Thanks again
Dave
Ok I am well out of my depth and will wait and see how things go.
Yea, same here ... but isn't it fun?!
I don't think it is that complicated though. I put off FPGAs for years but since I found those TTL libraries, I can program these chips in a language I understand - 'schematics'. Maybe eventually one has to look at vhdl and verilog, but I don't think so for the moment. Just draw a schematic, hit download and test it out.
Have you had a chance to download the software?
because
It seems DigiAsic and wayengineer have a lot of stuff...
That is a *very* nice find. I'll explain why I think this.
Ok, it doesn't really matter which FPGA or CPLD chip we choose, just tell the software and it will fit the schematic automatically. If it gets too big, get another chip. Some chips have more pins than others. Pretty much all are impossible to solder, but if they come out to headers it does not matter. So today I spent some hours designing an adapter board for some of the smaller chips. Ones with between 44 and 144 pins. Your board you have linked to, the one with the ram chip, http://www.ebay.com/itm/LC-ALTERA-EP2C8Q208-FPGA-Nios-II-core-board-/320749328856?pt=US_Ham_Radio_Transmitters&hash=item4aae2659d8, look at the pin numbers. They go from 64 to (I think) 199. There are missing numbers because there are ground pins everywhere, but that is different to the almost identical FPGA chip I was working with today, except that chip started with lower numbers. So even without a schematic, I think I can guess that what they have done is put the ram chip on the lower number pins. You *still* get two pin headers, almost packed with I/O pins.
So - out goes my Eagle PCB I designed today!
I was working today with different header configurations to try to talk to external memory chips with a 16 bit bus. No need with your board. It doesn't even matter what ram chip is on that board - if it is 8 bits we can synthesize some latches in the fpga and emulate a 16 pin bus or even more pins if we want. (for VGA, it is 16 to 18 pins, for touchscreens with a decent refresh rate eg for movies, it is 21 pins).
And I just noticed. The dual headers on that board are 50 pin, not 40 pin. So even more I/O pins. We can have a nice fat data pipe to the propeller, eg 8 bit data, /wr /rd and 2^6 virtual ports, and still have plenty of pins left over.
I can even start to think about my crazy Z80 computer that has a real Z80 chip rather than an emulation. Just so I can justify keeping the chips in a drawer in the shed for 30 years *grin*.
I have no idea what these part numbers mean either eg ep2c8q208 but plug it into the Quartus software and it tells me this is a cyclone ii chip. So ok, older technology, but that means cheaper boards. Quartus tells me this has 138 user I/O pins and 165888 memory bits, plus 8256 LEs (I don't know what they are, but they sound more than the number of elements on a CPLD).
Oh, and I'm still on the steep part of the learning curve too, but NIOS is a software processor used by Altera. It probably can do all sorts of clever boffinry.
Off to ebay to see if there are any fpga / ram combos that work out cheaper than $66 coz that is too much for me to justify to my other half as a hobby purchase...
...can even start to think about my crazy Z80 computer that has a real Z80 chip rather than an emulation...
Ha ha. No you can't. With your newly found FPGA skills you will soon be putting a Z80 configuration into an FPGA on some small and cheap board.
There are a few to choose from e.g. http://opencores.org/project,y80e
Sadly the guy doing the 8080 never did finish his plan to get CP/M running there.
Ah, you see, and we did get CP/M running on the propeller thanks to your crazy post some years back.
But it was just a tad slow, and that meant self compilation of programs was impractical (about 3 minutes for a typical C program). Self compilation is not a trivial thing - the propeller has yet to achieve this.
And I pushed CP/M to the limits with an MP/M emulation and there was a bug in the emulation and it was crashing about once every half an hour. So we never quite got MP/M either.
Not at all. It was realistically emulating the speed of that Super Brain and other CP/M machines of the era:)
We may have lost a bit on the processor speed but we made it up in the disk access speed. Those old floppies were much slower than SD cards.
I recall that a full recompile of an 8085 based control system I was working on back in the day took a whole working day even when the job was split over three machines that each had three eight inch floppy drives. Those were Intel dev systems at over £10,000 each.
(Mind you we did have four 8085's in that project with some shared RAM. I had been dreaming of a Propeller like multi-processor MCU ever since).
In the moment i prefer to use 2 XC9572 PLCC44 instead to use a XC95144XL TQFP144.
There is also PLCC84 ATF1508ASV-15-JU84, which looks to be a current part.
Depends on how much you need to couple between the two PLDs
If you need XC95144XL, then the MachXO2 is a better choice.
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
PCount - The pixelcounter, number of pixel in a row (10 bit)
HLCount - The horizontal line counter (10 bit)
VisArea - HIGH when the pixel is in the visible Area
A picture from the schematic symbol and the VHDL-Code from the VGACounter, it's untested !
Can be converted into a schematic symbol.
This is the second version of the VGACounter, it has 20 less outputs.
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
VisArea - HIGH when the pixel is in the visible Area
A picture from the schematic symbol and the VHDL-Code from the VGACounter2, it's untested !
Can be converted into a schematic symbol.
Please tell me what you think about the two VGACounters.
Are they good ? Must they improved ?
The best way to check is to look at the report files, check the logic levels and the MHz.
MHz is unlikely to be an issue at bottom-end VGA, but it gives an indication of margin, and too-long carry chains etc show up as a fall in MHz.
The CPLD Fitter reports (XC2C64 XC72xx) tend to be more readable than the FPGA reports, as the CPLD logic is less granular.
That means in the early stages of coding, you can target a CPLD, then flip to a FPGA if needed.
Check things like what the reset logic cost is, and how much logic the sync and gate pulses synth down to.
I would also add a very simple conditional debug pin, that creates a visible cross-hatch - keep it small by pick of say 4-5 lower bits in X & y . Then you can connect a test counter, directly to a VGA display and look at it.
I would also create a separate pin for Prop sync, which will be separately timed & one the Prop can Wait on.
I would also create a separate pin for Prop sync, which will be separately timed & one the Prop can Wait on.
I think the VisArea pin can be used for this.
It goes HIGH when HSYNC and YSYNC is HIGH.
It's the moment the data transmission from SDRAM to ADV7123 should start.
You mean a Zero Insertion Force (ZIF) test socket ? Why ?
I think the VisArea pin can be used for this.
It goes HIGH when HSYNC and YSYNC is HIGH.
It's the moment the data transmission from SDRAM to ADV7123 should start.
Usually you have front porch and back porch areas, outside the sync, so the visible pixel time, is less than Line-sync time.
Some monitors use sync and pixel info, when auto syncing, so it pays to have a 'valid' test case.
You also want to see vertical edges on screen, to check for jitter issues.
Google tqfp44 socket and you find the issues with this. They do exist, but are costly, and unlike PLCC44 sockets, they do not usually have a same-smd-footprint.
Normally they were only needed for device programming for non ISP parts.
Oh, that is not sounding too clever then. It should give a signature / device ID complaint with nothing on the far end.
Lucky I found that FT2232H can be used, with Atmel ISP SW.
Start with the same timing as display blanking, and from there it will fine-tune-earlier to interact with your software delays.
ie the actual start of video, will be some lines of sw after the Prop reacts and starts the burst read command.
Keep a real blanking signal, so you can probe the difference and verify you have the respond-delays right.
Display blanking is the time between Back Porch and Front Porch ?
Start with the same timing as display blanking, and from there it will fine-tune-earlier to interact with your software delays.
ie the actual start of video, will be some lines of sw after the Prop reacts and starts the burst read command.
Keep a real blanking signal, so you can probe the difference and verify you have the respond-delays right.
Must it be a counter or is a HIGH/LOW output good enough ?
A HBlank and a VBlank pin ?
Actual design:
XPos (0 - 799) and YPos (0 - 479) outputs the X- & Y- value from the pixel.
-- Pixel Clock = 25.175Mhz
-- Pixel Time = 0.04 usec
--
-- HSYNC = 3.84 µsec (96 Pixel), Back Porch = 1.92 µsec (48 Pixel)
-- Horizontal Video = 25.6 µsec (640 Pixel), Front Porch = 640 nsec (16 Pixel)
-- HSYNC + Back Porch + Horizontal Video + Front Porch = 32 µs (800 Pixel)
-- HSYNC = Pixel 0 - 95
-- Back Porch = Pixel 96 - 143
-- Horizontal Video = Pixel 144 - 783
-- Front Porch = Pixel 784 - 799
--
-- VSYNC = 0,064 ms (2 horiz. lines), Back Porch = 0.928ms (29 horiz. lines)
-- Vertical Video = 15.360 µsec (480 Pixel),
-- Front Porch = 0.320 ms (10 horiz. lines)
-- VSYNC + Back Porch + Vertical Video + Front Porch = 16.672ms (521 lines)
-- VSYNC = Line 0 - 1
-- Back Porch = Line 2 - 30
-- Vertical Video = Line 31 - 510
-- Front Porch = Line 511 - 520
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity VGACounter is
Port ( clk : in STD_LOGIC;
rst : in STD_LOGIC;
HSYNC : out STD_LOGIC := '0';
VSYNC : out STD_LOGIC := '0';
PCount : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
HLCount : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
XPos : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
YPos : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
VisArea : out STD_LOGIC := '0');
end VGACounter;
architecture Behavioral of VGACounter is
SIGNAL Pre_PCount : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_HLCount : STD_LOGIC_VECTOR(9 Downto 0) := "0000000000";
SIGNAL Pre_XPos : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_YPos : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_HSYNC : STD_LOGIC := '0';
SIGNAL Pre_VSYNC : STD_LOGIC := '0';
SIGNAL HVideo : STD_LOGIC := '0';
SIGNAL VVideo : STD_LOGIC := '0';
begin
PROCESS (clk, rst, Pre_PCount, Pre_HLCount, Pre_XPos, Pre_YPos, Pre_HSYNC, Pre_VSYNC, HVideo, VVideo)
begin
if rst = '0' then -- Reset is active (low)
HSYNC <= '0';
VSYNC <= '0';
Pre_HSYNC <= '0';
Pre_VSYNC <= '0';
Pre_PCount <= "0000000000";
Pre_HLCount <= "0000000000";
Pre_XPos <= "0000000000";
Pre_YPos <= "0000000000";
HVideo <= '0';
VVideo <= '0';
VisArea <= '0';
else
if clk = '1' then
Pre_PCount <= Pre_PCount + 1;
end if;
if Pre_PCount = 800 then
Pre_PCount <= "0000000000";
Pre_HLCount <= Pre_HLCount + 1;
if Pre_HLCount = 521 then
Pre_HLCount <= "0000000000";
end if;
End if;
end if;
if clk = '1' then
if Pre_PCount = 0 then -- End Front Porch, Begin HSYNC
Pre_HSYNC <= '0';
end if;
if Pre_PCount = 96 then -- END HSYNC, Begin Back Porch
Pre_HSYNC <= '1';
end if;
if Pre_PCount = 144 then -- End Back Porch, Begin visible Area
HVideo <= '1';
end if;
if Pre_PCount = 784 then -- End visible Area, Begin Front Porch
HVideo <= '0';
end if;
if Pre_HLCount = 0 then -- End Front Porch, Begin VSYNC
Pre_VSYNC <= '0';
end if;
if Pre_HLCount = 2 then -- END VSYNC, Begin Back Porch
Pre_VSYNC <= '1';
end if;
if Pre_HLCount = 31 then -- End Back Porch, Begin visible Area
VVideo <= '1';
end if;
if Pre_HLCount = 511 then -- End visible Area, Begin Front Porch
VVideo <= '0';
end if;
HSYNC <= Pre_HSYNC;
VSYNC <= Pre_VSYNC;
if HVideo = '1' and VVideo = '1' then -- X & Y Pixelposition is in visible Area
VisArea <= '1';
else
VisArea <= '0';
end if;
if (Pre_PCount > 143) and (Pre_PCount < 784) then -- Pixel X-Pos
Pre_XPos <= Pre_PCount - 144;
else
Pre_XPos <= "0000000000";
end if;
if (Pre_HLCount > 30) and (Pre_HLCount < 511) then -- Pixel Y-Pos
Pre_YPos <= Pre_HLCount - 31;
else
Pre_YPos <= "0000000000";
end if;
end if;
XPos <= Pre_XPos;
YPos <= Pre_YPos;
PCount <= Pre_PCount;
HLCount <= Pre_HLCount;
END PROCESS;
end Behavioral;
Must it be a counter or is a HIGH/LOW output good enough ?
A HBlank and a VBlank pin ?
A single pin is probably fine, it is really just a phase shifted VisArea, one edge can mean Send-Start-Burst, and the other edge can mean ok-to-write-data.
Registers Used : 0/144 (0%)
If that is right, you need to check your code. Looks to be no registers used, so you have no counters.... all combinatoric ?
In Verilog you need a posedge qualifier to get a register.
A single pin is probably fine, it is really just a phase shifted VisArea, one edge can mean Send-Start-Burst, and the other edge can mean ok-to-write-data.
In the old VGACounter version VisArea was set to HIGH when HSYNC and VSYNC was HIGH.
In the new version HVideo goes HIGH after the horizontal Back Porch and VVideo after the vertical Back Porch. They goes low when the Front Porch begins. When HVideo and VVideo are HIGH then is VisArea set to HIGH too, as long as one of them goes LOW !
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
HBlank - Goes HIGH at the begin from the Front Porch, goes LOW with the end from the Back Porch
VBlank - Goes HIGH at the begin from the Front Porch, goes LOW with the end from the Back Porch
Shift - Goes HIGH to signal SDRAM BURST START and LOW to signal SDRAM WRITE START
PCount - The pixelcounter, number of pixel in a row (10 bit), value between 0 - 799
HLCount - The horizontal line counter (10 bit), value between 0 - 520
XPos - The actual x-position from the pixel (10 bit), value between 0 - 639
YPos - The actual y-position from the pixel (10 bit), value between 0 - 479
VisArea - HIGH when the pixel is in the visible Area. XPOS & XPos are only valid when VisArea is HIGH !
A picture from the schematic symbol and the VHDL-Code from the VGACounter, it's untested !
Can be converted into a schematic symbol.
Target Device = XC95144XL-10TQ100 / XC95144XL-10TQ144
Optimization Method = SPEED
Macrocells Used = 90/144 (63%)
Pterms Used = 293/720 (41%)
Registers Used = 90/144 (63%)
Pins Used = 48/81 (60%) / 48/117 (42%)
Function Block Inputs Used = 114/432 (27%) / 100/432 (24%)
-- Pixel Clock = 25.175Mhz
-- Pixel Time = 0.04 usec
--
-- HSYNC = 3.84 µsec (96 Pixel), Back Porch = 1.92 µsec (48 Pixel)
-- Horizontal Video = 25.6 µsec (640 Pixel), Front Porch = 640 nsec (16 Pixel)
-- HSYNC + Back Porch + Horizontal Video + Front Porch = 32 µs (800 Pixel)
-- HSYNC = Pixel 0 - 95
-- Back Porch = Pixel 96 - 143
-- Horizontal Video = Pixel 144 - 783
-- Front Porch = Pixel 784 - 799
--
-- VSYNC = 0,064 ms (2 horiz. lines), Back Porch = 0.928ms (29 horiz. lines)
-- Vertical Video = 15.360 µsec (480 Pixel),
-- Front Porch = 0.320 ms (10 horiz. lines)
-- VSYNC + Back Porch + Vertical Video + Front Porch = 16.672ms (521 lines)
-- VSYNC = Line 0 - 1
-- Back Porch = Line 2 - 30
-- Vertical Video = Line 31 - 510
-- Front Porch = Line 511 - 520
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity VGACounter is
Port ( clk : in STD_LOGIC;
rst : in STD_LOGIC;
HSYNC : out STD_LOGIC := '0';
VSYNC : out STD_LOGIC := '0';
PCount : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
HLCount : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
XPos : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
YPos : out STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
HBlank : out STD_LOGIC := '1';
VBlank : out STD_LOGIC := '1';
Shift : out STD_LOGIC := '0';
VisArea : out STD_LOGIC := '0');
end VGACounter;
architecture Behavioral of VGACounter is
SIGNAL Pre_PCount : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_HLCount : STD_LOGIC_VECTOR(9 Downto 0) := "0000000000";
SIGNAL Pre_XPos : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_YPos : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_HSYNC : STD_LOGIC := '0';
SIGNAL Pre_VSYNC : STD_LOGIC := '0';
SIGNAL HVideo : STD_LOGIC := '0';
SIGNAL VVideo : STD_LOGIC := '0';
begin
PROCESS (clk, rst, Pre_PCount, Pre_HLCount, Pre_XPos, Pre_YPos, Pre_HSYNC, Pre_VSYNC, HVideo, VVideo)
begin
if rising_edge(clk) then
if rst = '0' then -- Reset is active (low)
HSYNC <= '0';
VSYNC <= '0';
Pre_HSYNC <= '0';
Pre_VSYNC <= '0';
Pre_PCount <= "0000000000";
Pre_HLCount <= "0000000000";
Pre_XPos <= "0000000000";
Pre_YPos <= "0000000000";
HBlank <= '1';
VBlank <= '1';
Shift <= '0';
HVideo <= '0';
VVideo <= '0';
VisArea <= '0';
else
Pre_PCount <= Pre_PCount + 1;
if Pre_PCount = 800 then
Pre_PCount <= "0000000000";
Pre_HLCount <= Pre_HLCount + 1;
if Pre_HLCount = 521 then
Pre_HLCount <= "0000000000";
end if;
End if;
end if;
if Pre_PCount = 0 then -- End Front Porch, Begin HSYNC
Pre_HSYNC <= '0';
end if;
if Pre_PCount = 96 then -- END HSYNC, Begin Back Porch
Pre_HSYNC <= '1';
end if;
if Pre_PCount = 144 then -- End Back Porch, Begin visible Area
HVideo <= '1';
end if;
if Pre_PCount = 784 then -- End visible Area, Begin Front Porch
HVideo <= '0';
end if;
if Pre_HLCount = 0 then -- End Front Porch, Begin VSYNC
Pre_VSYNC <= '0';
end if;
if Pre_HLCount = 2 then -- END VSYNC, Begin Back Porch
Pre_VSYNC <= '1';
end if;
if Pre_HLCount = 31 then -- End Back Porch, Begin visible Area
VVideo <= '1';
end if;
if Pre_HLCount = 511 then -- End visible Area, Begin Front Porch
VVideo <= '0';
end if;
HSYNC <= Pre_HSYNC;
VSYNC <= Pre_VSYNC;
if Pre_PCount = 784 then
HBlank <= '1';
end if;
if Pre_PCount = 144 then
HBlank <= '0';
end if;
if Pre_HLCount = 511 then
VBlank <= '1';
end if;
if Pre_HLCount = 31 then
VBlank <= '0';
end if;
if Pre_PCount = 142 then
Shift <= '1'; -- Means SDRAM BURST START
end if;
if Pre_PCount = 781 then
Shift <= '0'; -- Means SDRAM WRITE START
end if;
if HVideo = '1' and VVideo = '1' then -- X & Y Pixelposition is in visible Area
VisArea <= '1';
else
VisArea <= '0';
end if;
if (Pre_PCount > 143) and (Pre_PCount < 784) then -- Pixel X-Pos
Pre_XPos <= Pre_PCount - 144;
else
Pre_XPos <= "0000000000";
end if;
if (Pre_HLCount > 30) and (Pre_HLCount < 511) then -- Pixel Y-Pos
Pre_YPos <= Pre_HLCount - 31;
else
Pre_YPos <= "0000000000";
end if;
XPos <= Pre_XPos;
YPos <= Pre_YPos;
PCount <= Pre_PCount;
HLCount <= Pre_HLCount;
end if;
END PROCESS;
end Behavioral;
ISIM simulation runs with clock cycle 100ns on clk.
Comments
Yes you should be able to do timing from the CPLD or FPGA
eg http://www.johnloomis.org/altera/DE2/vga.html
As an aside, Eagle PCB seems to have library parts for Xilinx, Altera and Lattice. Most are tiny pin spacings/ball grid array but there are some PLCC packages and that means we could think about making our own boards too.
I see he also has two for AU$26.95, free shipping. Includes the 1.8V Core LDO, and some text mentions crystal, but I think that is confused...
Thanks for such a comprehensive reply.
Ok I am well out of my depth and will wait and see how things go.
It seems DigiAsic and wayengineer have a lot of stuff...
http://stores.ebay.com/wayengineer/category2370586015-/_i.html?_fsub=2370586015
But the part numbers are just that, numbers - to me, they mean nothing without doing lots of research, and that is out of the question at the moment.
I can see that when your interest is piqued you are like a dog with a rat, you won't let it go until you've devoured all you can find.
I will watch this thread with interest.
Thanks again
Dave
Yea, same here ... but isn't it fun?!
I don't think it is that complicated though. I put off FPGAs for years but since I found those TTL libraries, I can program these chips in a language I understand - 'schematics'. Maybe eventually one has to look at vhdl and verilog, but I don't think so for the moment. Just draw a schematic, hit download and test it out.
Have you had a chance to download the software?
because
That is a *very* nice find. I'll explain why I think this.
Ok, it doesn't really matter which FPGA or CPLD chip we choose, just tell the software and it will fit the schematic automatically. If it gets too big, get another chip. Some chips have more pins than others. Pretty much all are impossible to solder, but if they come out to headers it does not matter. So today I spent some hours designing an adapter board for some of the smaller chips. Ones with between 44 and 144 pins. Your board you have linked to, the one with the ram chip, http://www.ebay.com/itm/LC-ALTERA-EP2C8Q208-FPGA-Nios-II-core-board-/320749328856?pt=US_Ham_Radio_Transmitters&hash=item4aae2659d8, look at the pin numbers. They go from 64 to (I think) 199. There are missing numbers because there are ground pins everywhere, but that is different to the almost identical FPGA chip I was working with today, except that chip started with lower numbers. So even without a schematic, I think I can guess that what they have done is put the ram chip on the lower number pins. You *still* get two pin headers, almost packed with I/O pins.
So - out goes my Eagle PCB I designed today!
I was working today with different header configurations to try to talk to external memory chips with a 16 bit bus. No need with your board. It doesn't even matter what ram chip is on that board - if it is 8 bits we can synthesize some latches in the fpga and emulate a 16 pin bus or even more pins if we want. (for VGA, it is 16 to 18 pins, for touchscreens with a decent refresh rate eg for movies, it is 21 pins).
And I just noticed. The dual headers on that board are 50 pin, not 40 pin. So even more I/O pins. We can have a nice fat data pipe to the propeller, eg 8 bit data, /wr /rd and 2^6 virtual ports, and still have plenty of pins left over.
I can even start to think about my crazy Z80 computer that has a real Z80 chip rather than an emulation. Just so I can justify keeping the chips in a drawer in the shed for 30 years *grin*.
I have no idea what these part numbers mean either eg ep2c8q208 but plug it into the Quartus software and it tells me this is a cyclone ii chip. So ok, older technology, but that means cheaper boards. Quartus tells me this has 138 user I/O pins and 165888 memory bits, plus 8256 LEs (I don't know what they are, but they sound more than the number of elements on a CPLD).
Oh, and I'm still on the steep part of the learning curve too, but NIOS is a software processor used by Altera. It probably can do all sorts of clever boffinry.
Off to ebay to see if there are any fpga / ram combos that work out cheaper than $66 coz that is too much for me to justify to my other half as a hobby purchase...
Going back a step to older chips, throw "altera" at ebay and there are pulls http://www.ebay.com/itm/QTY-1x-Altera-EPM7128ALC84-10-Programmable-Logic-Device-EPM7128-/130890695590?pt=LH_DefaultDomain_0&hash=item1e79b183a6 for about the same price as a prop chip - PLCC sockets, 84 pins, at that price it ?might be better than some of the newer more complex chips? At least you could design a PCB to fit this rather than needing adapter boards.
I select first the XC9536XL and if it won't fit then i try the XC9572XL !
In the moment i prefer to use 2 XC9572 PLCC44 instead to use a XC95144XL TQFP144.
There are a few to choose from e.g.
http://opencores.org/project,y80e
http://opencores.org/project,cpu8080
Sadly the guy doing the 8080 never did finish his plan to get CP/M running there.
Do keep your Z80s in that drawer in the shed for a few decades longer though. There will be a museum that is very happy to have them sometime.
Ah, you see, and we did get CP/M running on the propeller thanks to your crazy post some years back.
But it was just a tad slow, and that meant self compilation of programs was impractical (about 3 minutes for a typical C program). Self compilation is not a trivial thing - the propeller has yet to achieve this.
And I pushed CP/M to the limits with an MP/M emulation and there was a bug in the emulation and it was crashing about once every half an hour. So we never quite got MP/M either.
Much to be done there is...
addit. still researching that 'sweet spot' of price vs performance. I really like this board http://www.ebay.com/itm/ALTERA-Cyclone-FPGA-Development-Board-JTAG-AS-SPI-Flash-EP1C3-Quartus-II-CPLD-/230960685109?pt=LH_DefaultDomain_0&hash=item35c6546035 as the pins come out as dual 40 pin headers, the I/O pins are contiguous, and the price is great. But it is a "cyclone I" board, and for some reason the Quartus starts at cyclone II. So don't buy this board! But if we can find one with a similar price/performance/simple i/o config it would be great. I think I might take a punt with http://www.ebay.com/itm/Altera-Cyclone-II-FPGA-EP2C5T144-Mini-Development-Learn-Core-Board-E081-/261095727391?pt=LH_DefaultDomain_0&hash=item3cca84a11f, as even though there is no schematic, it probably is fairly logical. Very similar to one from tritonium's site eg http://www.ebay.com/itm/DIGIASIC-FPGA-Altera-EP2C5T144-core-board-/221036386663?pt=US_Ham_Radio_Transmitters&hash=item3376cb9967 It may still end up better to add a ram chip ourselves rather than buy a board with a ram chip onboard...
We may have lost a bit on the processor speed but we made it up in the disk access speed. Those old floppies were much slower than SD cards.
I recall that a full recompile of an 8085 based control system I was working on back in the day took a whole working day even when the job was split over three machines that each had three eight inch floppy drives. Those were Intel dev systems at over £10,000 each.
(Mind you we did have four 8085's in that project with some shared RAM. I had been dreaming of a Propeller like multi-processor MCU ever since).
There is also PLCC84 ATF1508ASV-15-JU84, which looks to be a current part.
Depends on how much you need to couple between the two PLDs
If you need XC95144XL, then the MachXO2 is a better choice.
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
PCount - The pixelcounter, number of pixel in a row (10 bit)
HLCount - The horizontal line counter (10 bit)
VisArea - HIGH when the pixel is in the visible Area
A picture from the schematic symbol and the VHDL-Code from the VGACounter, it's untested !
Can be converted into a schematic symbol.
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
VisArea - HIGH when the pixel is in the visible Area
A picture from the schematic symbol and the VHDL-Code from the VGACounter2, it's untested !
Can be converted into a schematic symbol.
Are they good ? Must they improved ?
JMG, the 'send_xsvf.py -p com8 johnson_vc.xsvf' produce no error in the JTAGWhisperer !
The best way to check is to look at the report files, check the logic levels and the MHz.
MHz is unlikely to be an issue at bottom-end VGA, but it gives an indication of margin, and too-long carry chains etc show up as a fall in MHz.
The CPLD Fitter reports (XC2C64 XC72xx) tend to be more readable than the FPGA reports, as the CPLD logic is less granular.
That means in the early stages of coding, you can target a CPLD, then flip to a FPGA if needed.
Check things like what the reset logic cost is, and how much logic the sync and gate pulses synth down to.
I would also add a very simple conditional debug pin, that creates a visible cross-hatch - keep it small by pick of say 4-5 lower bits in X & y . Then you can connect a test counter, directly to a VGA display and look at it.
I would also create a separate pin for Prop sync, which will be separately timed & one the Prop can Wait on.
You mean a Zero Insertion Force (ZIF) test socket ? Why ?
Was that with a device connected, or no device ?
It goes HIGH when HSYNC and YSYNC is HIGH.
It's the moment the data transmission from SDRAM to ADV7123 should start.
No, i mean something like this PLCC sockets, but for the P8X32A-Q44 !
http://www.rm-computertechnik.de/Shop/picturesbig/PLCC-Sockel.jpg
Without a connected device !
Only JTAG.TDO is an output, the other JTAG lines are all inputs, seen from the PLD.
Usually you have front porch and back porch areas, outside the sync, so the visible pixel time, is less than Line-sync time.
Some monitors use sync and pixel info, when auto syncing, so it pays to have a 'valid' test case.
You also want to see vertical edges on screen, to check for jitter issues.
Google tqfp44 socket and you find the issues with this. They do exist, but are costly, and unlike PLCC44 sockets, they do not usually have a same-smd-footprint.
Normally they were only needed for device programming for non ISP parts.
Oh, that is not sounding too clever then. It should give a signature / device ID complaint with nothing on the far end.
Lucky I found that FT2232H can be used, with Atmel ISP SW.
http://openschemes.com/2011/10/25/bit-bang-jtag-programming-of-xilinx-cpld-using-ft232-homebrew-svf-player/6/
I test this tomorrow !
In the comments it seems to have good error messages, so it should complain on having no-device.
Then you will need a device to connect to it.
The Atmel ISP Sw expects a MPSSE device, so it only works on 2232D/2232H/2242H & I think 232H might work, but it is too new for the SW to recognize.
Start with the same timing as display blanking, and from there it will fine-tune-earlier to interact with your software delays.
ie the actual start of video, will be some lines of sw after the Prop reacts and starts the burst read command.
Keep a real blanking signal, so you can probe the difference and verify you have the respond-delays right.
Must it be a counter or is a HIGH/LOW output good enough ?
A HBlank and a VBlank pin ?
Actual design:
XPos (0 - 799) and YPos (0 - 479) outputs the X- & Y- value from the pixel.
Target Device Used: XC95144XL-10-TQ100
Optimization Method: SPEED
Macrocells Used
Pterms Used
Registers Used
Pins Used
Function Block Inputs Used
55/144 (39%)
638/720(89%)
0/144 (0%)
45/81 (56%)
198/432 (46%)
A single pin is probably fine, it is really just a phase shifted VisArea, one edge can mean Send-Start-Burst, and the other edge can mean ok-to-write-data.
Registers Used : 0/144 (0%)
If that is right, you need to check your code. Looks to be no registers used, so you have no counters.... all combinatoric ?
In Verilog you need a posedge qualifier to get a register.
Macro Statistics
# Adders/Subtractors: 4
10-bit adder : 2
10-bit subtractor : 2
# Latches : 11
1-bit latch : 7
10-bit latch : 4
In the new version HVideo goes HIGH after the horizontal Back Porch and VVideo after the vertical Back Porch. They goes low when the Front Porch begins. When HVideo and VVideo are HIGH then is VisArea set to HIGH too, as long as one of them goes LOW !
clk - VGA clock for 640X480 pixels with 60Hz, must be clocked with 25.175MHz.
rst - Reset (active LOW)
HSYNC - Horizontal sync signal
VSYNC - Vertical sync signal
HBlank - Goes HIGH at the begin from the Front Porch, goes LOW with the end from the Back Porch
VBlank - Goes HIGH at the begin from the Front Porch, goes LOW with the end from the Back Porch
Shift - Goes HIGH to signal SDRAM BURST START and LOW to signal SDRAM WRITE START
PCount - The pixelcounter, number of pixel in a row (10 bit), value between 0 - 799
HLCount - The horizontal line counter (10 bit), value between 0 - 520
XPos - The actual x-position from the pixel (10 bit), value between 0 - 639
YPos - The actual y-position from the pixel (10 bit), value between 0 - 479
VisArea - HIGH when the pixel is in the visible Area. XPOS & XPos are only valid when VisArea is HIGH !
A picture from the schematic symbol and the VHDL-Code from the VGACounter, it's untested !
Can be converted into a schematic symbol.
Target Device = XC95144XL-10TQ100 / XC95144XL-10TQ144
Optimization Method = SPEED
Macrocells Used = 90/144 (63%)
Pterms Used = 293/720 (41%)
Registers Used = 90/144 (63%)
Pins Used = 48/81 (60%) / 48/117 (42%)
Function Block Inputs Used = 114/432 (27%) / 100/432 (24%)
ISIM simulation runs with clock cycle 100ns on clk.