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
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.
Target Device = XC9536XL-10PC44
Optimization Method = SPEED
Macrocells Used = 30/36 (84%)
Pterms Used = 132/180 (74%)
Registers Used = 30/36 (84%)
Pins Used = 8/34 (24%)
Function Block Inputs Used = 40/108 (38%)
-- 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 VGACounter2 is
Port ( clk : in STD_LOGIC;
rst : in STD_LOGIC;
HSYNC : out STD_LOGIC := '0';
VSYNC : out STD_LOGIC := '0';
HBlank : out STD_LOGIC := '1';
VBlank : out STD_LOGIC := '1';
Shift : out STD_LOGIC := '0';
VisArea : out STD_LOGIC := '0');
end VGACounter2;
architecture Behavioral of VGACounter2 is
SIGNAL Pre_PCount : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000";
SIGNAL Pre_HLCount : 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_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";
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;
end if;
END PROCESS;
end Behavioral;
ISIM simulation runs with clock cycle 100ns on clk.
Shift - Goes two times HIGH for one clock cycle. First for SDRAM BURST START, second for SDRAM
The Prop can easily wait on either edge, so it might be easier to trouble shoot, if Rising edge does Read Trigger, and Falling edge does write trigger.
That way, during debug SW that takes too long, will not jump-phase, but simply skip a line.
To further assist debug, you could have the Prop output a 'waiting' pin change, just before the WAIT opcode.
That should always precede the hard-timing-GO signal, but not by too much, or you are wasting time...
When i replace the codeline: if rst = '0' then -- Reset is active (low)
through: if rst = '0' and rst'EVENT then -- Reset is active (low)
or: if falling_edge(rst) then -- Reset is active (low)
then i get the following message:
ERROR:Xst:827 - "G:/CPLD/Projekt/Test3/VGACounter2.vhd" line 45: Signal Pre_PCount cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release.
... cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release.
I'm less used to VHDL, but generally Counters prefer code more like
if falling_edge(clk) then
if rst = '0' then
Pre_PCount <= "0000000000"; -- Sync reset has priority
elsif Pre_PCount = 800 then
Pre_PCount <= "0000000000"; -- Terminal Count Reset is next
else
Pre_PCount <= Pre_PCount + 1; -- Count if none of the above true
end if;
End if;
Here you ask the logic to do one thing only, in one of 3 branches.
As always, check the fitter reports to see what it creates.
Post #242 has updated informations and downloads !
I think the VGACounters has now reached the final version.
Did you find the fitter report file (.rpt I think ?) - check the boolean equations, and generally it is better to have .D and .T over combin or Latch decodes. Less glitches and delays are then all matched on all pins.
Timed edges should optimize down to .T registers in a CPLD.
Yes, CPLDs have a fuse option for D-Flip-Flop and T-Flip-Flops, and Counters should choose the best of .D ,T
Sync-type pulses, should compile to 2 .T product terms.
Most CPLDs can use up to 5 Product terms ( show as OR eqn lines ) per macrocell, try to avoid constructs that balloon PTs.
eg using > is usually less efficient than using =
How can i ensure the compiler compile it in this way ?
Usually you just try various code constructs, and check the FIT report results.
Provided your expressions are not too complex, or overlapping, most tools seem to produce reasonable FIT results.
On some CPLD, there is also a Fan-In limit, for those it can help to create a node to collect common product terms, again, reading the FIT report and trying various constructs can better pack into parts.
FPGA arrived today. Actually, two of them arrived (another two are on the way).
I think it works. I can draw a schematic, compile it, and program it and it all seems to work as expected.
The USB Blaster was a nightmare to install. Took three hours and multiple searches on the internet. Windows simply refused to install the drivers saying they did not exist. Tried pointing at the 32 bit, 64 bit, blaster 1, blaster 2 directories and then even at some downloaded files. To cut a long story short, the secret is not to tell windows which directory the driver is in, but to tell it that the drivers are somewhere in c:\altera and to check the "check subdirectories" box.
And worth noting that this links to files and a website written by Leon Heller, who posts here on this forum from time to time.
One little thing I am not sure of - is my program permanent? It seems not, as it reverts to the pre programmed flashing led when cycling power. That tute mentions something about using the 'advanced serial' download for permanent programming, and jtag is for debugging. Guess I need to look into that.
Also need to think about adapter boards to talk to a propeller.
Anyway, I'll be able to catch up to you boffins soon!
The program that the power cycle is probably the one that is a "Demo" in some flash somewhere on the board and the running program was just the JTAG download of yours, just like the Prop's F10 and F11 then. Forgetting the setup on power cycles is a bit of a pain sometimes but a rebuild on the fly is wonderful and explains why so much kit takes forever to switch on and blanks out whilst mode changes are done.
I have collected a bunch of old CPLDs and FPGAs and the most recent one is the Spartan II, and I have dabbled with Xilinx CPLDs before. I have found more Cyclone (1) chips than I could ever use and might have to venture into Quatus II land. I think that Leon was more of a Altera person.
At least I have a couple of PCs that still have real serial and parallel ports on them.
Thanks Toby, that has sent me off in the right direction. Yes, there is a flash chip on the board, so it is very much like the propeller with an F10 and F11 mode.
I've got the one Leon has written up in this tutorial http://www.leonheller.com/FPGA/FPGA.html but I need to research exactly how to program the flash chip. There are two 10 pin headers on the board, one does jtag and the other does the flash chip, but the pinouts seem different so not sure how exactly to program the flash - ie can the USB blaster do this?
These demo boards have a few leds, a pushbutton and a xtal which is very handy as a starting point. No ram, but that may not be a disadvantage as there will be different ram chips for different applications.
General idea though and applies to Xilinx and Altera, is we can draw schematics and create custom chips very quickly. With an 8080 style bus (address, data, /wr /rd) to the propeller, data can be transferred quickly. So many possibilities. Many things are much better done on the propeller IMHO, eg SD card (as the software can be updated as cards change), quick TV display using 3 resistors, mouse, keyboard, serial. But other things are going to be better in the fpga, eg memory with a 16 bit data bus, talking to touchscreens, vga display.
It is the synergy between the two that I am particularly keen to explore.
In the moment i know how the ISE Project Navigator, Impact, Pace, iSIM and the CORE Generator works.
The navigator is the global management programm for the CPLD and FPGA programm design development.
Here can i draw schematics and write VDHL-files or can create VHDL-Testbenchs for iSIM.
Impact gives me the possibility to create SVF- or XSVF-Files.
When i have the Xilinx Plattform USB Cable i can programm the CPLD in the direct way, without the need for SVF- or XSVF-files.
Pace for the pin assignment, for the final pin position on the CPLD.
Here can i drag and drop the signal names to the pins.
If i want change a pin function, then i drag and drop the signal from one to a other pin.
The endresult with the locked pins is then stored in an ucf-file.
iSIM, with this can i simulate the CPLD behaviour after the programming.
I can create a clock signal for clk and let me show all outputs.
Like a multi-channel oscilloscope.
The CORE Generator is good for later, when i work with FPGA's too !
Here can i create RAM cores for the communication between the FPGA and the RAM.
1) Draw a schematic. Input pin. Inverter. Output Pin. See screenshot. I used a 74xx part as I understand them
2) Assignments/Pin Planner and it should come up with the two I/O pins. Double click on Location and scroll down and select the physical pins. From Leon Heller's tutorial, there is a pushbutton on pin 144, and leds on pins 3 7 and 9. So I picked 144 and 3.
3) Processing/Start Compilation (or use the shortcut button)
4) Tools/Programmer (or use the shortcut button)
5) Change the Mode to either JTAG or Active Serial. (in propeller language, F10 or F11)
6) Click Add Files. Browse to c:\altera\13\quartus\bin\output_files and there should be a .sof and a .pof file. sof is for F10 and pof is F11
7) This next bit got me for a while. To get the Start button to be ungrayed, you need to at least check the Program/Configure checkbox. It probably doesn't hurt to check the Verify box as well if it will let you.
8) For F10, plug the USB Blaster into the jtag header. For F11, plug it into the AS header.
9) Click on Start to download.
It is a bit convoluted with the 9 steps above but that does condense some huge official tutorials into something much simpler.
I used in my Silverado schematics the following ic's, all to handle the SDRAM.
The most are needed to save pins on the P8X32A.
2 X 74LV174N (Hex D-type flip-flop with reset)
8 X 74LVC1G57GW (Configurable multiple function gate)
6 X 74HC573N (Octal D-type transparent latch, 3-state)
2 X FST3257 (Quad 2:1 bus switch)
18 IC's
If i use two SDRAM's then things doubles !
The final pcb must be real huge !
But now i can handle the P8X32A <-> SDRAM -> ADV7123 communication with only one XC9572XL-7TQ100 and one XC9572XL-7PC44 CPLD's.
Makes 16 ic's less.
But one sdram is only 8 bits wide and that is not a very good color depth (RRRGGGBB or something similar). Not much better than the propeller itself. So it is going to need two ram chips (or a 16 bit wide chip, or pulling data out of an 8 bit chip at twice the rate).
I agree, only CPLDs and FPGAs can do this if you want to build it on a reasonable sized board.
But one sdram is only 8 bits wide and that is not a very good color depth (RRRGGGBB or something similar).
MT48LC32M16A2 – 8 Meg x 16 x 4 banks (RRRRRGGGGGGBBBBB)
16 bits are going from the SDRAM into the ADV7123 and 16bit makes 64K colors.
... then later is the time to think about how it should be done for a 24bit color information, if possible 1024X768X60Hz pixels.
Needs 65MHz clock frequence.
I have think something about sprite transparency.
One idea is to use a rrrrrgggggbbbbbt color information, t = pixel transpareny bit
But i have decide to use the sprite color information 0000000000000000 to sign its a transparent pixel, so the mcu don't copy it over the background.
Sprite Collision Detection
The next thing in the story is the sprite collision detection.
The left top edge x- and y- values from all sprites are stored into an array.
All sprites has a 16X16 pixel dimension.
In the first step a rectangle overlapping test for all sprites must be done.
When two rectangles are overlapped then is a pixel for pixel sprite collision test neccessary, but only for the pixels in the overlapping region from both rectangles. When two overlapping pixels are found then is the collsion test positiv and the other pixels from this two sprites must not be checked.
Sprite Handling
All sprites should be an instance from the c-class sprites.
In this are stored: x- and y-position, x- and y-speed, hitpoints and some ai rules for the behaviour.
Games Ideas
The first games should be in the manner like games as Frogger, Galaga, Galaxian or Turrican.
In a game like Frogger all sprites has a positiv or negativ x-axis speed, only the frogger can move along the y-axis. The other games has more complex sprite movements. Turrican has a additional feature, background scrolling.
I think a background scrolling should be able through the changement from the SDRAM Starting Column
Address as start point for the burst.
All inputs and outputs from the CPLD must be attached to a buffer element.
Is this true ?
Reading the link, that just looks like a means to tell the Schematic, and downstream flows, that you want a physical pin.
So yes, you will need a schematic symbol (buffer element) indicating what pin-type you want.
Some CPLDs also have pin-level options for Pin-Keep, Hysteresis, Pullup, Drive level/Speed, Open Drain, and somehow that info needs to make its way thru the flow to the fitter.
I have a question (Please take a look at the picture).
There is a green surrounded region. This is the SDRAM memory region with the data for the visible screen array (The viewport). 640 words x-axis and 480 words y-axis.
The red surrounded region is on all four sides 16 words wider. This is the background scrolling area.
The violett region is on all four sides 16 words wider. This is the spites dropzone. The sprites should have the ability to move from all sides into the visible area.
Can i change the beginning from the SDRAM full page burst in the way to move the viewport, in the red region, in all
directions to get a background scrolling effect ?
Can i change the beginning from the SDRAM full page burst in the way to move the viewport, in the red region, in all
directions to get a background scrolling effect ?
Yes, on SDRAM with 1024 page-size, you can move anywhere within that easily.
Even if you go outside, I think the SDRAM simply wraps, so there could be some interesting visual-wipe effects possible.
To simplify Prop-based blanking I was suggesting earlier having trailing pixels black, but if you want HW scroll, then the PLD Blanking signal becomes more important. It can be precise.
Comments
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
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.
Target Device = XC9536XL-10PC44
Optimization Method = SPEED
Macrocells Used = 30/36 (84%)
Pterms Used = 132/180 (74%)
Registers Used = 30/36 (84%)
Pins Used = 8/34 (24%)
Function Block Inputs Used = 40/108 (38%)
-- 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 VGACounter2 is Port ( clk : in STD_LOGIC; rst : in STD_LOGIC; HSYNC : out STD_LOGIC := '0'; VSYNC : out STD_LOGIC := '0'; HBlank : out STD_LOGIC := '1'; VBlank : out STD_LOGIC := '1'; Shift : out STD_LOGIC := '0'; VisArea : out STD_LOGIC := '0'); end VGACounter2; architecture Behavioral of VGACounter2 is SIGNAL Pre_PCount : STD_LOGIC_VECTOR(9 DOWNTO 0) := "0000000000"; SIGNAL Pre_HLCount : 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_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"; 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; end if; END PROCESS; end Behavioral;ISIM simulation runs with clock cycle 100ns on clk.
on what ?
The Prop can easily wait on either edge, so it might be easier to trouble shoot, if Rising edge does Read Trigger, and Falling edge does write trigger.
That way, during debug SW that takes too long, will not jump-phase, but simply skip a line.
To further assist debug, you could have the Prop output a 'waiting' pin change, just before the WAIT opcode.
That should always precede the hard-timing-GO signal, but not by too much, or you are wasting time...
through: if rst = '0' and rst'EVENT then -- Reset is active (low)
or: if falling_edge(rst) then -- Reset is active (low)
then i get the following message:
ERROR:Xst:827 - "G:/CPLD/Projekt/Test3/VGACounter2.vhd" line 45: Signal Pre_PCount cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release.
I'm less used to VHDL, but generally Counters prefer code more like
if falling_edge(clk) then if rst = '0' then Pre_PCount <= "0000000000"; -- Sync reset has priority elsif Pre_PCount = 800 then Pre_PCount <= "0000000000"; -- Terminal Count Reset is next else Pre_PCount <= Pre_PCount + 1; -- Count if none of the above true end if; End if;Here you ask the logic to do one thing only, in one of 3 branches.
As always, check the fitter reports to see what it creates.
I think the VGACounters has now reached the final version.
Did you find the fitter report file (.rpt I think ?) - check the boolean equations, and generally it is better to have .D and .T over combin or Latch decodes. Less glitches and delays are then all matched on all pins.
Timed edges should optimize down to .T registers in a CPLD.
Don't know exact what is meaned with '.D and .T over combin or latch decodes' !
I know the meaning of combin and latches, but .D and .T don't say much to me !
D-Flip-Flop and T-Flip-Flops ?
Yes, CPLDs have a fuse option for D-Flip-Flop and T-Flip-Flops, and Counters should choose the best of .D ,T
Sync-type pulses, should compile to 2 .T product terms.
Most CPLDs can use up to 5 Product terms ( show as OR eqn lines ) per macrocell, try to avoid constructs that balloon PTs.
eg using > is usually less efficient than using =
I have read in the datasheet:
Usually you just try various code constructs, and check the FIT report results.
Provided your expressions are not too complex, or overlapping, most tools seem to produce reasonable FIT results.
On some CPLD, there is also a Fan-In limit, for those it can help to create a node to collect common product terms, again, reading the FIT report and trying various constructs can better pack into parts.
Good that no one of my CPLD programms has errors or warnings in the report !
I think it works. I can draw a schematic, compile it, and program it and it all seems to work as expected.
The USB Blaster was a nightmare to install. Took three hours and multiple searches on the internet. Windows simply refused to install the drivers saying they did not exist. Tried pointing at the 32 bit, 64 bit, blaster 1, blaster 2 directories and then even at some downloaded files. To cut a long story short, the secret is not to tell windows which directory the driver is in, but to tell it that the drivers are somewhere in c:\altera and to check the "check subdirectories" box.
Quick note to myself - a 'getting started' guide http://www.etang.co.uk/datasheet/FPGA/Getting%20started%20with%20the%20EP2C5%20Cyclone%20II%20Mini%20Board.pdf
And worth noting that this links to files and a website written by Leon Heller, who posts here on this forum from time to time.
One little thing I am not sure of - is my program permanent? It seems not, as it reverts to the pre programmed flashing led when cycling power. That tute mentions something about using the 'advanced serial' download for permanent programming, and jtag is for debugging. Guess I need to look into that.
Also need to think about adapter boards to talk to a propeller.
Anyway, I'll be able to catch up to you boffins soon!
I have collected a bunch of old CPLDs and FPGAs and the most recent one is the Spartan II, and I have dabbled with Xilinx CPLDs before. I have found more Cyclone (1) chips than I could ever use and might have to venture into Quatus II land. I think that Leon was more of a Altera person.
At least I have a couple of PCs that still have real serial and parallel ports on them.
Video showing how to program the flash chip http://www.youtube.com/watch?v=ZrMe8JS7Ktk but that is with a different board to mine.
I've got the one Leon has written up in this tutorial http://www.leonheller.com/FPGA/FPGA.html but I need to research exactly how to program the flash chip. There are two 10 pin headers on the board, one does jtag and the other does the flash chip, but the pinouts seem different so not sure how exactly to program the flash - ie can the USB blaster do this?
Muddling my way through here. Manual http://www.altera.com/literature/ug/ug_usb_blstr.pdf suggests on page 9 that the USB blaster can also program the EPC2 device (which is the configuration eeprom), so fingers crossed, it is just a matter of plugging the 10 pin header in the other socket. This board shows the 10 pin header plugged into the AS header so that is encouraging http://www.canton-electronics.com/altera-fpga-development-board-fpga-board-usb-blaster-jtag-embedded-logic-analyzer-spi-flash-quartus-ii-ep1c3-p-582.html I'm still learning the lingo. For propellerheads, F10 is JTAG and F11 is AS. If that makes sense!
These demo boards have a few leds, a pushbutton and a xtal which is very handy as a starting point. No ram, but that may not be a disadvantage as there will be different ram chips for different applications.
General idea though and applies to Xilinx and Altera, is we can draw schematics and create custom chips very quickly. With an 8080 style bus (address, data, /wr /rd) to the propeller, data can be transferred quickly. So many possibilities. Many things are much better done on the propeller IMHO, eg SD card (as the software can be updated as cards change), quick TV display using 3 resistors, mouse, keyboard, serial. But other things are going to be better in the fpga, eg memory with a 16 bit data bus, talking to touchscreens, vga display.
It is the synergy between the two that I am particularly keen to explore.
The navigator is the global management programm for the CPLD and FPGA programm design development.
Here can i draw schematics and write VDHL-files or can create VHDL-Testbenchs for iSIM.
Impact gives me the possibility to create SVF- or XSVF-Files.
When i have the Xilinx Plattform USB Cable i can programm the CPLD in the direct way, without the need for SVF- or XSVF-files.
Pace for the pin assignment, for the final pin position on the CPLD.
Here can i drag and drop the signal names to the pins.
If i want change a pin function, then i drag and drop the signal from one to a other pin.
The endresult with the locked pins is then stored in an ucf-file.
iSIM, with this can i simulate the CPLD behaviour after the programming.
I can create a clock signal for clk and let me show all outputs.
Like a multi-channel oscilloscope.
The CORE Generator is good for later, when i work with FPGA's too !
Here can i create RAM cores for the communication between the FPGA and the RAM.
Let me write this up while I think of it. Yay, it can do F10 and F11. This is for Altera. http://www.ebay.com.au/itm/Altera-CycloneII-EP2C5T144-FPGA-Board-Altera-USB-Blaster-JTAG-programmer-/111015813741?pt=LH_DefaultDomain_15&hash=item19d90ee26d or just the board http://www.ebay.com.au/itm/Altera-CycloneII-EP2C5T144-FPGA-Mini-Development-Board-/150835820710?pt=LH_DefaultDomain_0&hash=item231e83f8a6 I found somewhere on the internet that someone in China has 10,000 of these in stock, so these should be a standard for a while. The header arrangements are a bit of a mess though with ground pins in amongst data pins. Might need an adapter board. Or maybe a different brand. Cyclone II seems a good price/performance to my eyes.
Anyway...
1) Draw a schematic. Input pin. Inverter. Output Pin. See screenshot. I used a 74xx part as I understand them
2) Assignments/Pin Planner and it should come up with the two I/O pins. Double click on Location and scroll down and select the physical pins. From Leon Heller's tutorial, there is a pushbutton on pin 144, and leds on pins 3 7 and 9. So I picked 144 and 3.
3) Processing/Start Compilation (or use the shortcut button)
4) Tools/Programmer (or use the shortcut button)
5) Change the Mode to either JTAG or Active Serial. (in propeller language, F10 or F11)
6) Click Add Files. Browse to c:\altera\13\quartus\bin\output_files and there should be a .sof and a .pof file. sof is for F10 and pof is F11
7) This next bit got me for a while. To get the Start button to be ungrayed, you need to at least check the Program/Configure checkbox. It probably doesn't hurt to check the Verify box as well if it will let you.
8) For F10, plug the USB Blaster into the jtag header. For F11, plug it into the AS header.
9) Click on Start to download.
It is a bit convoluted with the 9 steps above but that does condense some huge official tutorials into something much simpler.
Hey, this is fun!
The most are needed to save pins on the P8X32A.
2 X 74LV174N (Hex D-type flip-flop with reset)
8 X 74LVC1G57GW (Configurable multiple function gate)
6 X 74HC573N (Octal D-type transparent latch, 3-state)
2 X FST3257 (Quad 2:1 bus switch)
18 IC's
If i use two SDRAM's then things doubles !
The final pcb must be real huge !
But now i can handle the P8X32A <-> SDRAM -> ADV7123 communication with only one XC9572XL-7TQ100 and one XC9572XL-7PC44 CPLD's.
Makes 16 ic's less.
Excellent!
But one sdram is only 8 bits wide and that is not a very good color depth (RRRGGGBB or something similar). Not much better than the propeller itself. So it is going to need two ram chips (or a 16 bit wide chip, or pulling data out of an 8 bit chip at twice the rate).
I agree, only CPLDs and FPGAs can do this if you want to build it on a reasonable sized board.
16 bits are going from the SDRAM into the ADV7123 and 16bit makes 64K colors.
... then later is the time to think about how it should be done for a 24bit color information, if possible 1024X768X60Hz pixels.
Needs 65MHz clock frequence.
I have think something about sprite transparency.
One idea is to use a rrrrrgggggbbbbbt color information, t = pixel transpareny bit
But i have decide to use the sprite color information 0000000000000000 to sign its a transparent pixel, so the mcu don't copy it over the background.
Sprite Collision Detection
The next thing in the story is the sprite collision detection.
The left top edge x- and y- values from all sprites are stored into an array.
All sprites has a 16X16 pixel dimension.
In the first step a rectangle overlapping test for all sprites must be done.
When two rectangles are overlapped then is a pixel for pixel sprite collision test neccessary, but only for the pixels in the overlapping region from both rectangles. When two overlapping pixels are found then is the collsion test positiv and the other pixels from this two sprites must not be checked.
Sprite Handling
All sprites should be an instance from the c-class sprites.
In this are stored: x- and y-position, x- and y-speed, hitpoints and some ai rules for the behaviour.
Games Ideas
The first games should be in the manner like games as Frogger, Galaga, Galaxian or Turrican.
In a game like Frogger all sprites has a positiv or negativ x-axis speed, only the frogger can move along the y-axis. The other games has more complex sprite movements. Turrican has a additional feature, background scrolling.
I think a background scrolling should be able through the changement from the SDRAM Starting Column
Address as start point for the burst.
I have read on this website:
http://dangerousprototypes.com/docs/CPLD_intro_1:_Light_a_LED
Is this true ?
Reading the link, that just looks like a means to tell the Schematic, and downstream flows, that you want a physical pin.
So yes, you will need a schematic symbol (buffer element) indicating what pin-type you want.
Some CPLDs also have pin-level options for Pin-Keep, Hysteresis, Pullup, Drive level/Speed, Open Drain, and somehow that info needs to make its way thru the flow to the fitter.
There is a green surrounded region. This is the SDRAM memory region with the data for the visible screen array (The viewport). 640 words x-axis and 480 words y-axis.
The red surrounded region is on all four sides 16 words wider. This is the background scrolling area.
The violett region is on all four sides 16 words wider. This is the spites dropzone. The sprites should have the ability to move from all sides into the visible area.
Can i change the beginning from the SDRAM full page burst in the way to move the viewport, in the red region, in all
directions to get a background scrolling effect ?
Yes, on SDRAM with 1024 page-size, you can move anywhere within that easily.
Even if you go outside, I think the SDRAM simply wraps, so there could be some interesting visual-wipe effects possible.
To simplify Prop-based blanking I was suggesting earlier having trailing pixels black, but if you want HW scroll, then the PLD Blanking signal becomes more important. It can be precise.
Openschemes FT232 JTAG SVF Player V1.0 - http://openschemes.com/2013/06/22/openschemes-ft232-jtag-svf-player-v1-0/#comment-1144