R
Rick C. Hodgin
Guest
Does anybody work with Quartus II?
Best regards,
Rick C. Hodgin
Best regards,
Rick C. Hodgin
R
Rick C. Hodgin
Guest
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
> Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
> Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
R
Rick C. Hodgin
Guest
On Monday, December 15, 2014 2:11:21 PM UTC-5, gabor wrote:
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
Rick C. Hodgin wrote:
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
R
Rick C. Hodgin
Guest
On Monday, December 15, 2014 3:33:40 PM UTC-5, gabor wrote:
Interesting. Good to know. Thank you.
I will be setting up my CPU to do computation internally, and then to
communicate its state and computation to the outside world via a single
Ethernet port which will access memory internally, a handful of registers
to know what to send, and then send that data out the few pins required
for I/O with the Ethernet board.
Can I disable the trimming so all is computed?
Best regards,
Rick C. Hodgin
Rick C. Hodgin wrote:
On Monday, December 15, 2014 2:11:21 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
Unless the memory is external to the FPGA, which I presume would
add more ports to the top level design, then it really doesn't
matter how much "goes on inside." Unless the logic affects an
output, it will be trimmed from the design.
--
Gabor
Interesting. Good to know. Thank you.
I will be setting up my CPU to do computation internally, and then to
communicate its state and computation to the outside world via a single
Ethernet port which will access memory internally, a handful of registers
to know what to send, and then send that data out the few pins required
for I/O with the Ethernet board.
Can I disable the trimming so all is computed?
Best regards,
Rick C. Hodgin
G
GaborSzakacs
Guest
Rick C. Hodgin wrote:
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
G
GaborSzakacs
Guest
Rick C. Hodgin wrote:
Unless the memory is external to the FPGA, which I presume would
add more ports to the top level design, then it really doesn't
matter how much "goes on inside." Unless the logic affects an
output, it will be trimmed from the design.
--
Gabor
On Monday, December 15, 2014 2:11:21 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
Unless the memory is external to the FPGA, which I presume would
add more ports to the top level design, then it really doesn't
matter how much "goes on inside." Unless the logic affects an
output, it will be trimmed from the design.
--
Gabor
G
GaborSzakacs
Guest
Rick C. Hodgin wrote:
If the tools work as expected, you should not need to disable trimming
as long as the results of computation have some egress from the chip.
If there is no egress for the computational results, then the tools
should correctly determine that there was no point in doing the
computation, because you'd have no way of knowing that it happened.
So when your design has the Ethernet port, you should end up with
a full design in hardware. Until then it isn't clear why you
need to synthesize the design other than to find out how much
resources it takes. For that, you could certainly find an appropriate
tool setting to avoid trimming. I'm not a Quartus user, and my point
in replying in the first place was to say that your experience with
Quartus was not abnormal, as the same thing would happen in Xilinx
ISE tools. If you need help with Quartus, there is probably a lot
more traffic on the Altera website than you'll find in this news
group.
--
Gabor
On Monday, December 15, 2014 3:33:40 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, December 15, 2014 2:11:21 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
Unless the memory is external to the FPGA, which I presume would
add more ports to the top level design, then it really doesn't
matter how much "goes on inside." Unless the logic affects an
output, it will be trimmed from the design.
--
Gabor
Interesting. Good to know. Thank you.
I will be setting up my CPU to do computation internally, and then to
communicate its state and computation to the outside world via a single
Ethernet port which will access memory internally, a handful of registers
to know what to send, and then send that data out the few pins required
for I/O with the Ethernet board.
Can I disable the trimming so all is computed?
Best regards,
Rick C. Hodgin
If the tools work as expected, you should not need to disable trimming
as long as the results of computation have some egress from the chip.
If there is no egress for the computational results, then the tools
should correctly determine that there was no point in doing the
computation, because you'd have no way of knowing that it happened.
So when your design has the Ethernet port, you should end up with
a full design in hardware. Until then it isn't clear why you
need to synthesize the design other than to find out how much
resources it takes. For that, you could certainly find an appropriate
tool setting to avoid trimming. I'm not a Quartus user, and my point
in replying in the first place was to say that your experience with
Quartus was not abnormal, as the same thing would happen in Xilinx
ISE tools. If you need help with Quartus, there is probably a lot
more traffic on the Altera website than you'll find in this news
group.
--
Gabor
R
rickman
Guest
On 12/15/2014 3:50 PM, Rick C. Hodgin wrote:
I don't know how much formal education you have, but when I was at
University I was taught that an algorithm had several requirements (by
definition). One requirement was output since calculating whatever you
want is pointless unless the answer it provided to the outside world.
Your FPGA design is no different. What is the point of doing
computation if you don't provide some output to share the result?
Specifically to FPGA synthesis, it is not uncommon for the synthesis to
create logic that doesn't go anywhere. An example is the carry output
of an adder. When you infer an adder, often a full blown adder will be
used. Then in a later phase of the tools, the unused outputs from the
adder will be trimmed (such as the carry). The same goes for your
logic. If your code infers logic that feeds nothing that logic will be
trimmed.
There is no point to building a design with no output, even for testing,
since you have no way to tell if it is working.
Simulation is another matter. Trimming happens in synthesis.
Simulation doesn't trim, it simulates every line of code you write.
Simulation also allows you to view internal signals, so there is no need
for output.
I have suggested before that you not focus on hardware and testing your
design in a chip. There is very little you can't do as well, if not
much better in simulation than you can on a board. What is the
bandwidth of your scope? The simulator has infinite bandwidth for your
purposes.
--
Rick
On Monday, December 15, 2014 3:33:40 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, December 15, 2014 2:11:21 PM UTC-5, gabor wrote:
Rick C. Hodgin wrote:
On Monday, November 24, 2014 8:47:10 AM UTC-5, Rick C. Hodgin wrote:
Does anybody work with Quartus II?
I had an issue with their verilog compiler... code that compiled in
iverilog did not compile, and specifically one part was giving me an
error.
In order to get it to recognize top-level logic, the main module
needed to have an output port.
I had declared:
module oppie1();
It needed to be:
module oppie1(reg [0:0] out);
And then in initial:
initial begin
out = 1'b1;
end
The compiler then later gives the warning that out is stuck at VCC,
but it compiles and synthesizes!
Best regards,
Rick C. Hodgin
This is not a "quirk" of Quartus II. Most synthesis tools are built
to minimize the resource usage of the compiled design. If your design
has no outputs, and you intend to place it into a chip that doesn't
allow you to "look inside", then you essentially have a design that
does nothing. I think you'll also find that even with an output
in the port list, any logic that doesn't directly or indirectly
affect the value at that output will be trimmed away during synthesis
as well.
In your case the output is "stuck" at 1 because that's what your
code says to do. And since no other logic you could possibly place
inside the FPGA will affect that 1 output, it should all get trimmed
away. If you look at a usage report, it should tell you that the
design uses zero logic elements.
--
Gabor
I'll check it out.
The actual code is here if you want to look at it:
https://github.com/RickCHodgin/libsf/blob/master/li386/oppie/oppie1/oppie1.v
It does a lot internally, communicating with memory, processing data
through successive clock cycles, etc. That is just the header that
was required to get it to work.
Best regards,
Rick C. Hodgin
Unless the memory is external to the FPGA, which I presume would
add more ports to the top level design, then it really doesn't
matter how much "goes on inside." Unless the logic affects an
output, it will be trimmed from the design.
--
Gabor
Interesting. Good to know. Thank you.
I will be setting up my CPU to do computation internally, and then to
communicate its state and computation to the outside world via a single
Ethernet port which will access memory internally, a handful of registers
to know what to send, and then send that data out the few pins required
for I/O with the Ethernet board.
Can I disable the trimming so all is computed?
I don't know how much formal education you have, but when I was at
University I was taught that an algorithm had several requirements (by
definition). One requirement was output since calculating whatever you
want is pointless unless the answer it provided to the outside world.
Your FPGA design is no different. What is the point of doing
computation if you don't provide some output to share the result?
Specifically to FPGA synthesis, it is not uncommon for the synthesis to
create logic that doesn't go anywhere. An example is the carry output
of an adder. When you infer an adder, often a full blown adder will be
used. Then in a later phase of the tools, the unused outputs from the
adder will be trimmed (such as the carry). The same goes for your
logic. If your code infers logic that feeds nothing that logic will be
trimmed.
There is no point to building a design with no output, even for testing,
since you have no way to tell if it is working.
Simulation is another matter. Trimming happens in synthesis.
Simulation doesn't trim, it simulates every line of code you write.
Simulation also allows you to view internal signals, so there is no need
for output.
I have suggested before that you not focus on hardware and testing your
design in a chip. There is very little you can't do as well, if not
much better in simulation than you can on a board. What is the
bandwidth of your scope? The simulator has infinite bandwidth for your
purposes.
--
Rick