Custom timing on Altera Cyclone V GX dev board

[Rick C. Hodgin]

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

 

[Theo Markettos]

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

 

[Rick C. Hodgin]

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.

Theo

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?

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

 

[Theo Markettos]

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

 

[Rick C. Hodgin]

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.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

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

 

[Rick C. Hodgin]

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

 

[Rick C. Hodgin]

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

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?

Best regards,
Rick C. Hodgin

 

[Theo Markettos]

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

 

[Rick C. Hodgin]

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

 

[Rick C. Hodgin]

On Friday, December 30, 2016 at 10:06:45 AM UTC-5, Rick C. Hodgin wrote:

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.

I want my Logician tool to function more or less like this logic sim
tool:

https://www.kolls.net/gatesim/

Screenshot: https://www.kolls.net/gatesim/gatesim_ss.png

It has input, output, and an aggregation ability to create fundamental
circuits which can then be manipulated as larger constructs, as in the
image with the "half adder."

I want to provide noodle connections (as in that image), as well as
square/diagonal-routed lines. I want to provide a "tactical" view
which shows things in block diagram concept, as well as a "details"
view which shows circuits, and to be able to enable those settings
on individual components within. I want to be able to drill down
into an aggregation to see the fundamental circuits, and to be able
to leave those settings enabled in future views.

I also want to do it all in OpenGL because I eventually want to
create a process generation feature, which will physically generate
the circuits (in 3D) used for creating transistors on a substrate,
along with all wiring, placement, and routing. I want it to give
users the ability to take concepts from idea, to design, to testing
and debugging, to physical layout and placement on a semiconductor
substrate.

My goals ultimately are to create a primitive fabrication facility
called Sand Castle Fabs, which uses antiquated process technologies
that are well mature and inexpensive to allow the creation of custom
ICs without the huge cost of modern fabs. That's a goal I have for
the latter half of the 2020s.

Best regards,
Rick C. Hodgin