I have a "Cyclone V GX Starter Board," with an Altera Cyclone V GX 5CGXFC5CF27C7N. I've designed a logic layout for a video card that only does SVGA output in graphics modes, and particularly only 1024 x 768 x 75 Hz refresh rate right now. I've developed a custom protocol for using single bytes per pixel, and a palette of 256 colors from a possible range of 4,096 colors. ----- I've gotten everything designed and I'd like to put it to hardware now. I honestly don't know where to begin on this Altera. I'd like to double-clock the pixel clock so I can conduct operations in-between use. It requires about a 79 MHz clock at 1024x768x75, so I'd need about a 168 MHz clock. Can somebody point me in the right direction, please? Best regards, Rick C. Hodgin
Custom timing on Altera Cyclone V GX dev board
Started by ●December 7, 2016
Reply by ●December 7, 20162016-12-07
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:> I've gotten everything designed and I'd like to put it to hardware > now. I honestly don't know where to begin on this Altera. > > I'd like to double-clock the pixel clock so I can conduct operations > in-between use. It requires about a 79 MHz clock at 1024x768x75, > so I'd need about a 168 MHz clock. > > Can somebody point me in the right direction, please?You need a PLL. You can either: Go to IP Catalog in Quartus and instantiate one. This has a wizard that asks you all the questions and generates some Verilog that does it. It's then up to you to wire it up. or If you use Qsys (a good idea) you can just drop in a PLL component and fill in the answers to the questions. You can then connect up the ports with the clicky interface - which will also keep track of your clock domains and insert clock crossing buffers where needed. Theo
Reply by ●December 7, 20162016-12-07
On Wednesday, December 7, 2016 at 2:09:37 PM UTC-5, Theo Markettos wrote:> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > I've gotten everything designed and I'd like to put it to hardware > > now. I honestly don't know where to begin on this Altera. > > > > I'd like to double-clock the pixel clock so I can conduct operations > > in-between use. It requires about a 79 MHz clock at 1024x768x75, > > so I'd need about a 168 MHz clock. > > > > Can somebody point me in the right direction, please? > > You need a PLL. You can either: > > Go to IP Catalog in Quartus and instantiate one. This has a wizard that > asks you all the questions and generates some Verilog that does it. It's > then up to you to wire it up. > > or > > If you use Qsys (a good idea) you can just drop in a PLL component and fill > in the answers to the questions. You can then connect up the ports with the > clicky interface - which will also keep track of your clock domains and > insert clock crossing buffers where needed. > > TheoWill I be able to create a 158 MHz clock on this device? Or is that beyond its abilities? Also, I have add and compare circuits that need to run at about 79 MHz. Will those work properly? I'm moving from the area of digital theory design to FPGA programming reality. I'm not sure what to expect. Best regards, Rick C. Hodgin
Reply by ●December 7, 20162016-12-07
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:> Will I be able to create a 158 MHz clock on this device? Or is that > beyond its abilities? Also, I have add and compare circuits that need > to run at about 79 MHz. Will those work properly?The /device/ should be capable of up to 300-400MHz - at least that's what I've seem in general use. However it's your problem to make a design that will run at the speed you use to run it at. I wouldn't have thought you would have big problems at 79MHz, and might be OK at 158MHz - it really depends. TimeQuest timing analyser will tell you, among other things, the maximum clock speed that each clock domain will run at. Assuming you have constrained your input clocks appropriately (ie have an SDC file that indicates their speeds, and any relations between them) then Timequest will warn if your design fails to meet your timing constraints. If you have a PLL, it knows the input clock and will calculate the speeds of the generated clocks, so in general you just need to tell it the input speeds and it'll figure out the rest.> I'm moving from the area of digital theory design to FPGA programming > reality. I'm not sure what to expect.You might find it useful to have a read through an intro to the tools - for instance this my brief rundown aimed at second year university students (in the middle of a course doing other things including verilog and bare-metal software development): http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html Theo
Reply by ●December 7, 20162016-12-07
On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > Will I be able to create a 158 MHz clock on this device? Or is that > > beyond its abilities? Also, I have add and compare circuits that need > > to run at about 79 MHz. Will those work properly? > > The /device/ should be capable of up to 300-400MHz - at least that's what > I've seem in general use. However it's your problem to make a design that > will run at the speed you use to run it at. I wouldn't have thought you > would have big problems at 79MHz, and might be OK at 158MHz - it really > depends. > > TimeQuest timing analyser will tell you, among other things, the maximum > clock speed that each clock domain will run at. Assuming you have > constrained your input clocks appropriately (ie have an SDC file that > indicates their speeds, and any relations between them) then Timequest will > warn if your design fails to meet your timing constraints. If you have a > PLL, it knows the input clock and will calculate the speeds of the generated > clocks, so in general you just need to tell it the input speeds and it'll > figure out the rest. > > > I'm moving from the area of digital theory design to FPGA programming > > reality. I'm not sure what to expect. > > You might find it useful to have a read through an intro to the tools - for > instance this my brief rundown aimed at second year university students (in > the middle of a course doing other things including verilog and > bare-metal software development): > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > TheoExcellent info. Thank you, Theo. I'm meeting with a local hardware project Meetup group this weekend, so hopefully I'll pick up a few pointers. They typically go over a design and build from beginning to end that one of the members from the group has already had success in getting it to work. Best regards, Rick C. Hodgin
Reply by ●December 8, 20162016-12-08
On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote:> On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote: > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > > Will I be able to create a 158 MHz clock on this device? Or is that > > > beyond its abilities? Also, I have add and compare circuits that need > > > to run at about 79 MHz. Will those work properly? > > > > The /device/ should be capable of up to 300-400MHz - at least that's what > > I've seem in general use. However it's your problem to make a design that > > will run at the speed you use to run it at. I wouldn't have thought you > > would have big problems at 79MHz, and might be OK at 158MHz - it really > > depends. > > > > TimeQuest timing analyser will tell you, among other things, the maximum > > clock speed that each clock domain will run at. Assuming you have > > constrained your input clocks appropriately (ie have an SDC file that > > indicates their speeds, and any relations between them) then Timequest will > > warn if your design fails to meet your timing constraints. If you have a > > PLL, it knows the input clock and will calculate the speeds of the generated > > clocks, so in general you just need to tell it the input speeds and it'll > > figure out the rest. > > > > > I'm moving from the area of digital theory design to FPGA programming > > > reality. I'm not sure what to expect. > > > > You might find it useful to have a read through an intro to the tools - for > > instance this my brief rundown aimed at second year university students (in > > the middle of a course doing other things including verilog and > > bare-metal software development): > > > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > > > Theo > > Excellent info. Thank you, Theo. > > I'm meeting with a local hardware project Meetup group this weekend, > so hopefully I'll pick up a few pointers. They typically go over a > design and build from beginning to end that one of the members from > the group has already had success in getting it to work.I'm going to start by trying to get the address generation circuit and read memory working. I have designed a staging register, and a use register, so the next 8-byte read can come in the background while the pixel clock is shifting between 8-bit blocks in the use register. I think this will provide adequate timing for video modes even well beyond 1024 x 768 x 75 Hz. Best regards, Rick C. Hodgin
Reply by ●December 10, 20162016-12-10
On Thursday, December 8, 2016 at 3:12:44 PM UTC-5, Rick C. Hodgin wrote:> On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote: > > On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote: > > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > > > Will I be able to create a 158 MHz clock on this device? Or is that > > > > beyond its abilities? Also, I have add and compare circuits that need > > > > to run at about 79 MHz. Will those work properly? > > > > > > The /device/ should be capable of up to 300-400MHz - at least that's what > > > I've seem in general use. However it's your problem to make a design that > > > will run at the speed you use to run it at. I wouldn't have thought you > > > would have big problems at 79MHz, and might be OK at 158MHz - it really > > > depends. > > > > > > TimeQuest timing analyser will tell you, among other things, the maximum > > > clock speed that each clock domain will run at. Assuming you have > > > constrained your input clocks appropriately (ie have an SDC file that > > > indicates their speeds, and any relations between them) then Timequest will > > > warn if your design fails to meet your timing constraints. If you have a > > > PLL, it knows the input clock and will calculate the speeds of the generated > > > clocks, so in general you just need to tell it the input speeds and it'll > > > figure out the rest. > > > > > > > I'm moving from the area of digital theory design to FPGA programming > > > > reality. I'm not sure what to expect. > > > > > > You might find it useful to have a read through an intro to the tools - for > > > instance this my brief rundown aimed at second year university students (in > > > the middle of a course doing other things including verilog and > > > bare-metal software development): > > > > > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > > > > > Theo > > > > Excellent info. Thank you, Theo. > > > > I'm meeting with a local hardware project Meetup group this weekend, > > so hopefully I'll pick up a few pointers. They typically go over a > > design and build from beginning to end that one of the members from > > the group has already had success in getting it to work. > > I'm going to start by trying to get the address generation circuit and > read memory working. I have designed a staging register, and a use > register, so the next 8-byte read can come in the background while the > pixel clock is shifting between 8-bit blocks in the use register. > > I think this will provide adequate timing for video modes even well > beyond 1024 x 768 x 75 Hz.I began working with Altera's Quartus II software last night and had difficulty in understanding how it works. In addition, as I began to write verilog code to reproduce my design, it loses so much in the translation into text. I've decided to complete my Logician tool so I can do a graphical design and then have it generate gate, wire, and net verilog source code for compilation in the tool. I'm an image/design-thinker ... not a convert-to-text-thinker. :-) Best regards, Rick C. Hodgin
Reply by ●December 29, 20162016-12-29
On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > Will I be able to create a 158 MHz clock on this device? Or is that > > beyond its abilities? Also, I have add and compare circuits that need > > to run at about 79 MHz. Will those work properly? > > The /device/ should be capable of up to 300-400MHz - at least that's what > I've seem in general use. However it's your problem to make a design that > will run at the speed you use to run it at. I wouldn't have thought you > would have big problems at 79MHz, and might be OK at 158MHz - it really > depends. > > TimeQuest timing analyser will tell you, among other things, the maximum > clock speed that each clock domain will run at. Assuming you have > constrained your input clocks appropriately (ie have an SDC file that > indicates their speeds, and any relations between them) then Timequest will > warn if your design fails to meet your timing constraints. If you have a > PLL, it knows the input clock and will calculate the speeds of the generated > clocks, so in general you just need to tell it the input speeds and it'll > figure out the rest. > > > I'm moving from the area of digital theory design to FPGA programming > > reality. I'm not sure what to expect. > > You might find it useful to have a read through an intro to the tools - for > instance this my brief rundown aimed at second year university students (in > the middle of a course doing other things including verilog and > bare-metal software development): > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.htmlI've been working on designing my L1 cache: https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1 https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png And I'm about ready to program in a single 128-byte cache row and see if I can get it working. I'm going to write it externally and produce Verilog code using gates and nets. If I get it to a point where I think it's all there, but it's still not working, would you be willing to help me debug it? Best regards, Rick C. Hodgin
Reply by ●December 29, 20162016-12-29
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:> I've been working on designing my L1 cache: > > https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1 > https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png > > And I'm about ready to program in a single 128-byte cache row and see > if I can get it working. I'm going to write it externally and produce > Verilog code using gates and nets. > > If I get it to a point where I think it's all there, but it's still > not working, would you be willing to help me debug it?I can't help you debug, since it's your design that only you know on hardware only you have access to. Debugging is a very personal penance. However I suggest you have a look at ModelSim for simulation of your design - Altera have a free version with some limitations. For running on hardware SignalTap gives you visibility of what's going on inside - with the limitation that the number of signals and time are limited and it typically involves frequent resynthesis cycles. Hardware debugging can be slow and it helps to think carefully about what you want to view before each synthesis run - simulation has much better visibility shorter round-trip times, so it's worth starting there unless you really need hardware. Theo
Reply by ●December 30, 20162016-12-30
On Thursday, December 29, 2016 at 5:26:11 PM UTC-5, Theo Markettos wrote:> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > I've been working on designing my L1 cache: > > > > https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1 > > https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png > > > > And I'm about ready to program in a single 128-byte cache row and see > > if I can get it working. I'm going to write it externally and produce > > Verilog code using gates and nets. > > > > If I get it to a point where I think it's all there, but it's still > > not working, would you be willing to help me debug it? > > I can't help you debug, since it's your design that only you know on > hardware only you have access to. Debugging is a very personal penance. > > However I suggest you have a look at ModelSim for simulation of your design > - Altera have a free version with some limitations. For running on hardware > SignalTap gives you visibility of what's going on inside - with the > limitation that the number of signals and time are limited and it typically > involves frequent resynthesis cycles. Hardware debugging can be slow and it > helps to think carefully about what you want to view before each synthesis > run - simulation has much better visibility shorter round-trip times, so it's > worth starting there unless you really need hardware.I appreciate your input, Theo. Thank you for your help. I would prefer to do it in simulation. I have plans to create a tool to do exactly that. In fact, I've been building that cache design in both my mind and GIMP (graphics software). With my simulation tool, called Logician, I would be able to create that basic image in a similar designer which is not just creating the image, but is connecting the wires together, having gate blocks which appear graphical as in my image, but contain underlying real logic. I may go ahead and get that tool done so I can work on those things in simulation. If I had that tool completed, I would actually like to complete my entire CPU and run it in simulation. Best regards Rick C. Hodgin