6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Nov 23, 2024 1:13 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programmable Logic

All times are UTC




Post new topic Reply to topic  Page 4 of 6
  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
  Print view Previous topic | Next topic 
Author Message
MichaelM
PostPosted: Mon Aug 11, 2014 6:15 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
EEyE:

That's cool. I was reading and thinking about the integer square root function that Dr. Crenshaw published this weekend. Really impressed that it can be implemented succintly in Verilog as your code shows.

_________________
Michael A.
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Mon Aug 11, 2014 8:24 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
MichaelM wrote:
EEyE:

That's cool. I was reading and thinking about the integer square root function that Dr. Crenshaw published this weekend. Really impressed that it can be implemented succintly in Verilog as your code shows.

I hope to use it to control amplitude of the sin or cos table Xilinx has generated from LUTs and I've stored in BRAM.... Not sure yet. But I am borrowing the following .GIF from the sine wiki so the general idea can be seen, although I currently modify the phase for ellipse. A strictly horizontal or vertical ellipse requires amplitude modulation for the sin or cos.


Attachments:
Circle_cos_sin.gif
Circle_cos_sin.gif [ 516.79 KiB | Viewed 2258 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Sun Sep 07, 2014 8:15 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I still haven't made any headway into generating a sine wave with a controllable amplitude from a LUT, so I decided to tackle another portion of the project which needs attention, i.e. how to resolve video ram contention with cpu/hardware accelerator access. Also, on this projects' software side of things, I am attempting to port Bruce's take on Bob Bishop's Mandelbrot program to 65Org16. I will start a new thread on that very soon...

Now as far as the video databus contention issue, I am not pleased when the cpu only has access during non active Hsync or non active Vsync. It's very slow and old hat, quite honestly.
Even though I'm not as good as some EE's out there that have experience with scanline buffers, FIFOs and dual port FPGA blockRAMs, I think I have an idea after doing more than a little bit of research and some testing.

The GS8320Z18 SyncRAM I'm using has a 4.0ns delay time in flow through mode which I currently use with a 150MHz pixel clock. So it is within the 250MHz limit in flow though mode. In pipelined mode the delay is spec'd at 2.5ns which would allow the device to run at 400MHz. The device is not hardwired selected for this mode, however I am currently running it in flow through mode at 300MHz. And it does seem to be working for some states of my hardware graphics accelerator, which is exciting to see since the goal would be to have interleaved access to the SyncRAM and it is possible to do back to back read and/or writes with this ZBT RAM. A post by a member named PK gave me more confidence this idea would work on this thread in other electronics forum. Lots of good links to follow from this guy!

So now I have to re-test 6 of the 8 functions this hardware generator has that plots directly to the syncRAM and try to fix up timing issues:
Line Generator............: not 100%
Rectangular fill............: not 100%
Pixel Plot...................: appears working
Read Pixel Color...........: appears working
Copy & Paste Rectangle: not working
Character Plot.............: not 100%

The project has 4 clocks generated utilizing the Spartan 6 PLL_ADV from an onboard 100MHz can oscillator:
1) 75MHz 65Org16 cpu/hardware accelerator/FPGA blockRAMs used for coordinate storage
2) 300MHz 2MBx16 Synchronous RAM (videoram)
3) 150MHz pixel clock to videoDAC and H/V Sync generator
4) 150MHz main signal to next Parallel Video Board (unused presently)

EDIT:
I realize I may be violating some timing spec's of the syncRAM since it's running 50MHz above spec, so all this is just a test at 1920x1080 with the realization this may not work at this speed.
Finally added in bypass cap's for the syncRAM with no change in behavior. (I suspect the properties of the board material are providing good enough capacitance for power supply filtering)
Tried changing syncRAM pin drive strength and slew rate from the FPGA with no better performance.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Tue Sep 16, 2014 11:05 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
This past experiment was a failure as expected...
I have reached the limitations, in my current knowledge of Verilog, with this board design. I'm still working on the Mandelbrot 65Org16 software on spare time which will take advantage of the current capabilities I've developed.

I'm currently looking at a new design where I will recycling the 4 SYncRAMs I'm currently using across 4 PVB's and put them onto 2 newly designed boards @1920x1080 @150MHz. Each board will have 2 x 2Mx18 4ns GSI SyncRAMs and a larger Spartan 6 IC's in a BGA style package. The FPGA will have 2 separate address and data buses for them. The old backplane will still be able to support up to 6 of these new PVB's because the I/O connector will be the same 96-pin 3-row style. The idea behind the 2 SyncRAM's is to make 2 possibilities an easy reality: 1) is for sprites. 2) is for buffer for the videoDAC.

I'm looking at a new PCB maunfacturer called eurocircuits. They've been mentioned here before in other threads. They're very reasonably priced and are capable of up to 16 layers. Also a great many board construction variables can be set by the maker, and finally checked by their ordering system. They favor the Eagle so I'll have to learn this program as I was used to EPCB.

What really turned me on to them is that since I'll be mounting my own BGA packages now, they offer custom stencils not only for the BGA packages but for the entire board for ~$50 for a 4"x3" board. One can order a stencil for the top and/or the bottom!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Tue Sep 16, 2014 11:33 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
ElEctric_EyE wrote:
They favor the Eagle so I'll have to learn this program as I was used to EPCB.

Almost all board houses accept industry-standard gerber files; so any CAD that produces them will work. That would be any except the ones done by board houses that want to lock you into their service alone. If you supply gerber files (gerber files for the copper layers, excellon for drill files), the board house won't care what CAD you used, and they don't have to have even heard of it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Tue Sep 16, 2014 11:42 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Garth, check out their PCB guidelines on page 3 of their PCB Design PDF link.

I was about to look into OrCad until I did more research into this PCB manufacturing house.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Wed Sep 17, 2014 2:30 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
The top of page 3 is approximately what I would expect. Note that there are some board houses that won't accept gerber RS-274D anymore, only 274X; but I learned to convert it quickly by hand in the text editor a few years ago, and it made it a lot easier to get what I wanted. When we only had 274D, doing complex layers (e.g., a ground plane with splits and other cuts in it) took detailed instructions in the readme file to tell them how to put various files together to get what you want-- and then they would still mess up sometimes and use the wrong aperture file or something. 274X is so much nicer and eliminates a lot of chances for human error on their part.

We used OrCAD at the place I worked from 1985-'92, and it had more bugs than an ant hill. It was terrible! Hopefully they've improved since then; but I see they still haven't learned to draw the schematic symbol for a resistor correctly after all these years, so maybe I shouldn't expect much.

Note that they say if it's directly CAD files, it can only be from Eagle; but if your files are gerber & excellon as mentioned at the top of the page, they can be from any CAD.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Wed Sep 17, 2014 11:26 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Garth, 2 questions quickly come to mind regarding this new path I'm taking on this 6-layer board using the Cadsoft Eagle program for PCB design. I'm researching them, but you may already know:
1) Can one use the Eagle program for PCB development without the schematic entry first? My initial experience seems like it wants a schematic first.
2) Since I aim for 6 layers and 2 power planes, should I have slower signals on the top and bottom planes? Then the Power and Ground planes, then finally sandwiched in the middle planes are the higher speed signals which would provide a natural bypass capacitance using FR4 material?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Thu Sep 18, 2014 5:45 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
EE, I'm not familiar with Eagle, but I'm sure you don't need to use the schematic capture if you don't want to. My CAD (Easy PC Pro) has schematic capture but I don't like the way any of the schematic captures I've tried work, so I still do my schematics by hand; but in the CAD, I can still pick the devices out of the libraries I built and put the parts on a board and connect them up the way I want, without using the ratsnesting and such. Even though the CAD came with libraries with lots of parts pre-made, I've made my own for denser layouts. But regardless, there will always be various parts that won't come in any CAD's pre-made libraries, so you need to be able to make those parts. Recent examples for me have included a chip antenna, feedthru capacitor, balun, various inductors, and chip crystals.

Normally the order of the layers in a 6-layer board is approximately what you mention:

  • signal 1 generally going at 0°
  • power (bypassed to ground at all Vcc pins and anywhere a trace goes through a via from layer 1 to layer 6 if the signals are fast enough to matter since otherwise the return current cannot keep following the signal trace)
  • signal 2 generally going 45°
  • signal layer 3 generally going 135°
  • ground
  • and signal layer 4 generally going 90°.

Which signal layers are 0, 45, 90, and 135° is not really important except that it's good to have the 2nd and 3rd signal layers at 90° to each other to reduce inter-layer coupling, since they're next to each other. Having signal layers generally going the directions shown above will greatly reduce the number of vias you need.

Trying to keep the fastest signals on the inside may make it harder to route a dense board, and is not necessary anyway because if the power and ground layers are used correctly, you already have transmission lines that will keep from radiating or picking up noise even if they're on the outside. Just route a signal on the layer that goes the general direction that signal needs to go. When I worked in VHF/UHF power transistor applications engineering in the mid-1980's and was often building up power amplifiers for engineering testing of our parts under the conditions requested by the clients, we always used microstrip or coplanar waveguide, not stripline. In microstrip, the transmission line is always on the top, yet there's no radiation from it. In stripline, the signal lines are sandwiched between ground layers (and one could be a power plane bypassed to ground at places that are appropriate for the signal line).

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Wed Sep 24, 2014 12:38 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Great information as always Garth. Many thanks for trying to help me!

I spent about 2 weeks trying to rise above the learning curve for Cadsoft Eagle and realized it was going to take up too much of the little time I have left to spare for this new chapter of the PVB project.

I've decided to stick with the PCB routing software I already know from Express PCB as I can route 90% of all the available signals off of the FPGA necessary with about 30 extra I/O pins left over using their ProtoPro service which limits the total board design to 21 square inches. 4 boards for $205US. The new boards will be 6"x3.5" vs the these current 3.8"x2.5" PVBs. The new boards will now have some new features, the most important being 2x 2Mx18 SyncRAMs for sprite generation or page flipping.

The following code and associated videos will show the speed of the 75 MHz 65Org16 working in unison with 8 functions of my 75MHz hardware graphics accelerator written in Verilog. The SyncRAM and Arlet's Hsync/VSync/pixel clock generator are running @150MHz. Thanks to Arlet way back, I have hsync and vsync signals from the SYNC generator going to the 65Org16 cpu through an expanded 16-bit status flag register, and also branch testing opcodes for branch on clear or set for the added status flag bits. I have yet to post this version of 65Org16 on Github.

The hardware accelerator uses the RDY flag in order to halt the cpu so the accelerator can do it's work on the videoRAM. However, there is still video interference when the software chooses not to plot without regarding the state of hvsync or vsync and so video interference results.

Since I am going to have to cannibalize the memory IC's from 4 out of the 5 boards, I thought that the best way to close this thread would be to display some basic functions, especially with different delay variables.

Each post will include the 65Org16 coding and the video. This is more for me than anyone else and I thank 6502.org for tolerating my indulgence, but hopefully some may find it interesting and inspirational since I started designing the first version of these boards back in Aug 6, 2012. I did it in order to learn the discipline of the Verilog language. I'm a slow learner, but hardware design goes in tandem with HDL, so the design must change for the little I now know.

Here are the 8 functions of the current 2D hardware accelerator:
Code:
8/26/2014 smg    Programming the 16-bit 2D Graphics 'LineGen' Accelerator
               
FUNCTION...............VARIABLE = 'description'....................R(ead)/W(rite)
________________________________________________________________________________
   
Line Generator............color = pixel color..........................RW
                            lx0 = X position start.....................RW
                            ly0 = Y position start.....................RW
                            lx1 = X position end.......................RW
                            ly1 = Y position end(*)....................RW
                     
Rectangle Fill............color = pixel color..........................RW
                          fXlen = Horizontal length....................RW
                          fYlen = Vertical length......................RW
                            fXs = X position start.....................RW
                            fYs = Y position start(*)..................RW
                     
Pixel Plot................color = pixel color..........................RW
                             Xp = X position...........................RW
                             Yp = Y position(*)........................RW

Read Pixel Color.............Xr = X position...........................RW
                             Yr = Y position(*)........................RW
                      colordata = 5-6-5 16bit R-G-B color data.........R
                                             
Copy & Paste Rectangle....bXlen = Horizontal length....................RW
                          bYlen = Vertical length......................RW
                            bXc = X position start of copy.............RW
                            bYc = Y position start of copy.............RW
                            bXp = X position start of paste............RW
                            bYp = Y position start of paste(*).........RW
                       
Character Plot............color = pixel color..........................RW
                         bcolor = background pixel color...............RW
                            Att = ASCII character + font...............RW
                             (0000000axxxxxxxx. xxxxxxxx = 8bit ASCII)
                             (a = 1 C64, a = 0 DOS. FONTS)
                             cX = X position...........................RW
                             cY = Y position(*)........................RW
                       
SIN LUT Generator........Xblock = (0..15) BRAM LUTs for X coordinates..RW
                         Yblock = (0..15) BRAM LUTs for Y coordinates..RW
                        Xoffset = placement within 1920 Horizontal.....RW
                        Yoffset = placement within 1080 Vertical.......RW
                          xfreq = # of SIN repetition within LUT1......RW
                          yfreq = # of SIN repetition within LUT2......RW
                         Xphase = (0..1023) Phase input to LUT1........RW
                         Yphase = (0..1023) Phase input to LUT2(*).....RW
                       
Square Root Generator........Xs = 16bit number.........................RW
                             Ys = 16bit number(*)......................RW
                           Root = SQRT(Xs^2 + Ys^2)....................R
________________________________________________________________________________
NOTES:
(*) This Verilog Hardware Function is initiated after a write to these registers.



Also, bear with me as it take longer to process video through youtube so the software will most likely be posted first.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Wed Sep 24, 2014 1:23 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
This is software to init the 64Kx16 ZeroPage & 64Kx16 StackPage pointers within the 65Org16 (only 1Kx16 used for each utilizing FPGA BRAMs). This is because early on I allowed the cpu to directly access the videoRAM for things like plotting characters through software and screen clearing. That is before I understood how to make Verilog perform these functions in HDL... The videoRAM started at $00000000. This is no longer allowed, the accelerator now performs all the plotting, so this is legacy code (I just now realize :roll: ). Also this code initializes the H/V Sync Generator timings and then clears the videoRAM using the Rectangle Fill with color #%0000000000000000 (black):
Code:
BEGIN:            LDA #$1000             
                  TAZP                    ;SET ZEROPAGE @$1000_0000
                  LDA #$1001
                  TASP                    ;SET STACKPAGE @$1001_0000                 
                                                                                                                   
                  LDA #1920               ;2430 (2200 ideal for 67.5kHz) total H cycles      @148.5MHz 16.363uS ->  61.111kHz         
                  STA hVIDEO                                                                       
                  LDA #205                 ;205                                                     
                  STA hFRONT                                                                       
                  LDA #50                  ;50                                                   
                  STA hSYNC                                                                       
                  LDA #255                 ;255                                                     
                  STA hBACK
                 
                  LDA #1080                ;1139 total     @148.5MHz ->  1139 x 16.363uS = 18.638mS = 53.654Hz
                  STA vVIDEO                                                                               
                  LDA #2                   ;2                                                             
                  STA vFRONT                                                                               
                  LDA #55                  ;55                                                           
                  STA vSYNC                                                                                 
                  LDA #2                   ;2                                                             
                  STA vBACK                                                                                                             
                 
rock              LDA #%0000000000000000                  ;16-bit 565 RGB               
                  STA color
                 
                  LDA #1919
                  STA fXlen
                  LDA #1079
                  STA fYlen
                  LDA #0
                  STA fXs
                  STA fYs                  ;FILL!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Wed Sep 24, 2014 1:39 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Continuing, this final part of this software draws lines from the center of the screen to the outer edges with a significant delay. The variable 'color' is derived from a pseudo-random HDL number generator. It's not so random as every number is the same upon power-up but it does the job OK. Next board will have a true random number generator built in hardware.
Code:
BEGIN:            LDA #$1000             
                  TAZP                    ;SET ZEROPAGE @$1000_0000
                  LDA #$1001
                  TASP                    ;SET STACKPAGE @$1001_0000                 
                                                                                                                                       
                  LDA #1920               ;2430 (2200 ideal for 67.5kHz) total H cycles      @148.5MHz 16.363uS ->  61.111kHz         
                  STA hVIDEO                                                                       
                  LDA #205                 ;205                                                     
                  STA hFRONT                                                                       
                  LDA #50                  ;50                                                   
                  STA hSYNC                                                                       
                  LDA #255                 ;255                                                     
                  STA hBACK
                 
                  LDA #1080                ;1139 total     @148.5MHz ->  1139 x 16.363uS = 18.638mS = 53.654Hz
                  STA vVIDEO                                                                               
                  LDA #2                   ;2                                                             
                  STA vFRONT                                                                               
                  LDA #55                  ;55                                                           
                  STA vSYNC                                                                                 
                  LDA #2                   ;2                                                             
                  STA vBACK                                                                                                             
                 
rock              LDA #%0000000000000000                  ;16-bit 565 RGB               
                  STA color
                 
                  LDA #1919
                  STA fXlen
                  LDA #1079
                  STA fYlen
                  LDA #0
                  STA fXs
                  STA fYs                  ;FILL!

                  LDA rng
                  STA color
                 
                  LDX #0
                  LDA #1920/2
                  STA lx0
                  LDA #1080/2
                  STA ly0
liner1            TXA
                  STA lx1
                  JSR DELAY2
                  LDA #0
                  STA ly1
                  INX
                  CPX #1919
                  BNE liner1
                 
                  LDX #0
                  LDA #1920/2
                  STA lx0
                  LDA #1080/2
                  STA ly0
liner2            TXA
                  STA lx1
                  JSR DELAY2
                  LDA #1080
                  STA ly1
                  INX
                  CPX #1919
                  BNE liner2
                 
                  LDY #0
                  LDA #1920/2
                  STA lx0
                  LDA #1080/2
                  STA ly0
                  LDA #0
                  STA lx1
liner3            TYA
                  STA ly1
                  JSR DELAY2
                  INY
                  CPY #1080
                  BNE liner3
                 
                  LDY #0
                  LDA #1920/2
                  STA lx0
                  LDA #1080/2
                  STA ly0
                  LDA #1919
                  STA lx1
liner4            TYA
                  STA ly1
                  JSR DELAY2
                  INY
                  CPY #1080
                  BNE liner4

                  JMP rock

Here is the DELAY2 routine:
Code:
DELAY2            PHY
                  PHX
                  LDY #$0FFF
GHJ               DEY
                  BNE GHJ
                  PLX
                  PLY
                  RTS

Quite a few cycles! I'll ry to make the video tonight.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
ElEctric_EyE
PostPosted: Wed Sep 24, 2014 2:24 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
This video is with the delay.
This video is without delay.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Wed Sep 24, 2014 5:45 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Thanks EEye for taking us on this journey with you! It's easy enough for two years to pass without any visible progress, so congratulations for showing the determination to bring this design to a demo-worthy state and posting about your problems and progress. I'm sure you feel satisfied that you've learnt a huge amount by battling through this far: we don't often cast ourselves back to the beginning of a project and consider what used to be mysterious to us, or what we felt to be beyond our understanding.

Cheers
Ed
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Wed Sep 24, 2014 3:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
BigEd wrote:
Thanks EEye for taking us on this journey with you!

I've been reading about this project as well as it progressed. As Ed noted, it's easy to lose sight of the early days when success of any kind seemed uncertain and some problems seemed insurmountable. You've come a long ways with it. :)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 4 of 6
  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 5 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.