EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

creating program

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - creating program

Goto page Previous  1, 2, 3, 4  Next


Guest

Mon Nov 09, 2015 1:50 pm   



On Sunday, November 1, 2015 at 8:27:30 AM UTC+1, rickman wrote:

Quote:
I think your distinction is pointless. You said "VHDL is a description,
not a program" and I have you an example when this is not true. End of
discussion for me.


Fine. That doesn't mean you're right.

Quote:
As to the "mindset", there was a software designer who wanted to code an
FPGA in VHDL and came here asking for advice. We told him about how he
needed to adjust his thinking to design hardware and not code software.
I wrote to him personally to explain why this was important and came
close to getting some consulting time with his firm. In the end his
bosses had faith that he could do a good job and so he wrote the code
himself, without any trouble.


It's a whole different thing, assuming the end result ends up on a FPGA. Software is sequenced, around datastructures. VHDL is not sequenced, and doesn't have thing software has : Lock issues, memory alignment issues, etc.

With software, you attach a debugger, and you can step through. With VHDL, it's not that simple. So yes, I call this a different mindset. If you think like a software programmer, you'll sooner or later end up with a non-working, hard to debug prototype.

Quote:
I learned that although I was a hardware person who was able to more
easily think about the hardware I was designing as gates and register,
this is *not* required, rather you *can* write VHDL as a sequential
language as long as you understand the various processes were all in
parallel. Parallel processes are not unique to hardware.


I doubt that still works for a *very* large design. On software, the OS handes a lot for you. No cache flushes, no memory barriers, etc.

Can a programmer while VHDL code ? Sure. But there is a huge different between good and "it works". Every monkey can write PHP code, but writing good, maintainable code is a different story.


Igmar

Andy
Guest

Tue Nov 10, 2015 5:04 am   



On Monday, November 9, 2015 at 5:50:51 AM UTC-6, igmar.pa...@boostermedia.com wrote:
Quote:
It's a whole different thing, assuming the end result ends up on a FPGA. Software is sequenced, around datastructures. VHDL is not sequenced, and doesn't have thing software has : Lock issues, memory alignment issues, etc.

Really? You think a modern SW compiler doesn't tweak your sequence to take advantage of the processor's capabilities. Whether it's SW or HW: coder, know thy compiler!


And who says data structures are exclusive to SW? Oh, you mean they aren't available in Verilog? Use a better language!

> With software, you attach a debugger, and you can step through. With VHDL, it's not that simple. So yes, I call this a different mindset. If you think like a software programmer, you'll sooner or later end up with a non-working, hard to debug prototype.

So you don't use the debugger to set breakpoints and step through complex RTL? I guess maybe not if you code too close to the edif.

Been developing FPGAs in VHDL like SW (enlightened by digital HW circuit design experience) for 20+ years now. Have fewer problems than when I tried to code netlists, doing the synthesis tool's job for it. Sure it's not _exactly_ like SW, but many, many principles of SW development are highly applicable to RTL.

> I doubt that still works for a *very* large design. On software, the OS handes a lot for you. No cache flushes, no memory barriers, etc.

I would beg to differ. Very large designs are where SW approaches make the most sense and benefit. The larger the design (and body of code), the harder it is to maintain if you don't think about it like SW.

Cache flushes are not unique to SW. The OS is just more SW. So we need to write a little more code to do that in RTL.

Quote:

Can a programmer while VHDL code ? Sure. But there is a huge different between good and "it works". Every monkey can write PHP code, but writing good, maintainable code is a different story.


Yes there is a difference between SW and HW, nobody is denying that. But I've reviewed, maintained, and debugged too many RTL designs written too close to the netlist level not to recognize the benefits of SW approach to RTL.

You have to know where to pay attention to the HW (async clock boundaries are a big chunk). Then handle that close to the HW level, but encapsulate it into a few reusable entities (like system calls to the OS in SW) and then concentrate on the function, throughput and latency of the rest of the design. On a multi-person team, only one or two need to deal with the low level stuff, the rest can design at a much higher level, where the behavior of the code is critical.

Andy

rickman
Guest

Tue Nov 10, 2015 3:15 pm   



On 11/9/2015 6:50 AM, igmar.palsenberg_at_boostermedia.com wrote:
Quote:
On Sunday, November 1, 2015 at 8:27:30 AM UTC+1, rickman wrote:

I think your distinction is pointless. You said "VHDL is a description,
not a program" and I have you an example when this is not true. End of
discussion for me.

Fine. That doesn't mean you're right.


??? You don't make sense. I give you an example of VHDL that is a
program as used everyday and you reject that???


Quote:
As to the "mindset", there was a software designer who wanted to code an
FPGA in VHDL and came here asking for advice. We told him about how he
needed to adjust his thinking to design hardware and not code software.
I wrote to him personally to explain why this was important and came
close to getting some consulting time with his firm. In the end his
bosses had faith that he could do a good job and so he wrote the code
himself, without any trouble.

It's a whole different thing, assuming the end result ends up on a FPGA. Software is sequenced, around datastructures. VHDL is not sequenced, and doesn't have thing software has : Lock issues, memory alignment issues, etc.


I don't think you understand VHDL. VHDL has sequential code, that is
what a process it.


> With software, you attach a debugger, and you can step through. With VHDL, it's not that simple. So yes, I call this a different mindset. If you think like a software programmer, you'll sooner or later end up with a non-working, hard to debug prototype.

Huh??? I use single stepping with VHDL at times. Normally it isn't
that useful because there is so much parallelism, things tend to jump
around as one process stops and another starts... same as software on a
processor with interrupts or multitasking.


Quote:
I learned that although I was a hardware person who was able to more
easily think about the hardware I was designing as gates and register,
this is *not* required, rather you *can* write VHDL as a sequential
language as long as you understand the various processes were all in
parallel. Parallel processes are not unique to hardware.

I doubt that still works for a *very* large design. On software, the OS handes a lot for you. No cache flushes, no memory barriers, etc.

Can a programmer while VHDL code ? Sure. But there is a huge different between good and "it works". Every monkey can write PHP code, but writing good, maintainable code is a different story.


I'm not sure what you are going on about. You started by saying "VHDL
is a description, not a program." Now you seem to be splitting all
manner of hairs and calling programmers "monkeys".

Why don't we agree to disagree?

--

Rick

Igmar Palsenberg
Guest

Thu Nov 12, 2015 9:36 am   



Op dinsdag 10 november 2015 04:04:31 UTC+1 schreef Andy:
Quote:
On Monday, November 9, 2015 at 5:50:51 AM UTC-6, igmar.pa...@boostermedia..com wrote:
It's a whole different thing, assuming the end result ends up on a FPGA.. Software is sequenced, around datastructures. VHDL is not sequenced, and doesn't have thing software has : Lock issues, memory alignment issues, etc..

Really? You think a modern SW compiler doesn't tweak your sequence to take advantage of the processor's capabilities. Whether it's SW or HW: coder, know thy compiler!


Sure.

> And who says data structures are exclusive to SW? Oh, you mean they aren't > available in Verilog? Use a better language!

Datastructures come at a price. In software the're cheap, in hardware the're less cheap. I need to think harder in VHDL about the structure in general.. I find myself far less limited in software (which is also a potential problem, if you ask me)

Quote:
With software, you attach a debugger, and you can step through. With VHDL, it's not that simple. So yes, I call this a different mindset. If you think like a software programmer, you'll sooner or later end up with a non-working, hard to debug prototype.

So you don't use the debugger to set breakpoints and step through complex RTL? I guess maybe not if you code too close to the edif.


I did that on old Altera software. I failed at the latest version, still need to look into that. In IntelliJ, it just attach and it works (c).

> Been developing FPGAs in VHDL like SW (enlightened by digital HW circuit design experience) for 20+ years now. Have fewer problems than when I tried to code netlists, doing the synthesis tool's job for it. Sure it's not _exactly_ like SW, but many, many principles of SW development are highly applicable to RTL.

True. I have 20+ in software, not in hardware. Getting up-to-speed on VHDL again, which I last used at the university (that was 15 years ago).

Quote:
I doubt that still works for a *very* large design. On software, the OS handes a lot for you. No cache flushes, no memory barriers, etc.

I would beg to differ. Very large designs are where SW approaches make the most sense and benefit. The larger the design (and body of code), the harder it is to maintain if you don't think about it like SW.


In what sense ? Cutting it up in the right modules you mean ? I especially found the VHDL variable vs signals confusing, and that fact that it looks sequential, but isn't.

> Cache flushes are not unique to SW. The OS is just more SW. So we need to write a little more code to do that in RTL.

I haven't reached that point yet :)

Quote:

Can a programmer while VHDL code ? Sure. But there is a huge different between good and "it works". Every monkey can write PHP code, but writing good, maintainable code is a different story.

Yes there is a difference between SW and HW, nobody is denying that. But I've reviewed, maintained, and debugged too many RTL designs written too close to the netlist level not to recognize the benefits of SW approach to RTL.

You have to know where to pay attention to the HW (async clock boundaries are a big chunk). Then handle that close to the HW level, but encapsulate it into a few reusable entities (like system calls to the OS in SW) and then concentrate on the function, throughput and latency of the rest of the design. On a multi-person team, only one or two need to deal with the low level stuff, the rest can design at a much higher level, where the behavior of the code is critical.


I'm still struggling testing in VHDL. With software, I'm more confortable : Junit, gtest, mockito, pick one or combine them.
That's getting harder in the modern async works : Akka for example is message based, high-parallel.

I'm looking at vunit for VHDL at the moment, but it's still a bit confusing : Waveform in, waveform out. With software it's value in, value out.



Igmar

Igmar Palsenberg
Guest

Thu Nov 12, 2015 9:41 am   



Op dinsdag 10 november 2015 09:15:13 UTC+1 schreef rickman:
Quote:
On 11/9/2015 6:50 AM, igmar.palsenberg_at_boostermedia.com wrote:
On Sunday, November 1, 2015 at 8:27:30 AM UTC+1, rickman wrote:

I think your distinction is pointless. You said "VHDL is a description,
not a program" and I have you an example when this is not true. End of
discussion for me.

Fine. That doesn't mean you're right.

??? You don't make sense. I give you an example of VHDL that is a
program as used everyday and you reject that???


As to the "mindset", there was a software designer who wanted to code an
FPGA in VHDL and came here asking for advice. We told him about how he
needed to adjust his thinking to design hardware and not code software..
I wrote to him personally to explain why this was important and came
close to getting some consulting time with his firm. In the end his
bosses had faith that he could do a good job and so he wrote the code
himself, without any trouble.

It's a whole different thing, assuming the end result ends up on a FPGA.. Software is sequenced, around datastructures. VHDL is not sequenced, and doesn't have thing software has : Lock issues, memory alignment issues, etc..

I don't think you understand VHDL. VHDL has sequential code, that is
what a process it.


But all of t hem run parallel. With software, it's the other way around.

Quote:
With software, you attach a debugger, and you can step through. With VHDL, it's not that simple. So yes, I call this a different mindset. If you think like a software programmer, you'll sooner or later end up with a non-working, hard to debug prototype.

Huh??? I use single stepping with VHDL at times. Normally it isn't
that useful because there is so much parallelism, things tend to jump
around as one process stops and another starts... same as software on a
processor with interrupts or multitasking.


That's also getting more common in software these days. Ever tried debugging a 1M messages / second Akka application ?

I've used Altera's Max Plus II, that only had waveforms. Hooking a real simulator up with Quartus failed for me. I might try the Xilinx tools, see if I have better luck with them.


Quote:
Can a programmer while VHDL code ? Sure. But there is a huge different between good and "it works". Every monkey can write PHP code, but writing good, maintainable code is a different story.

I'm not sure what you are going on about. You started by saying "VHDL
is a description, not a program." Now you seem to be splitting all
manner of hairs and calling programmers "monkeys".


I was trying to point out there is a difference between getting something to work, and actually understanding it. I failed at that :)


Igmar

Igmar Palsenberg
Guest

Thu Nov 12, 2015 7:00 pm   



> Processes run in parallel in both VHDL and in software.

That can only be done if :

a) You have multiple cores / processors
b) You have an OS that supports it

If either of them are not met, it all runs sequential.

Quote:
In software your
process may be *hugely* complex doing many, many things in each one.
Partly that's because there is a huge overhead for setting up and
managing each process in software. In VHDL a process has no overhead in
the implementation. I'm not sure how complex process management is in
simulation. I've not heard it is a problem though. The speed problems in
simulation often come from the data structures. Integers are faster than
std_logic, et. al.


I don't expect that simulation runs at fullspeed. Similar tools in software usually also have an overhead.

Quote:
I've used Altera's Max Plus II, that only had waveforms. Hooking a
real simulator up with Quartus failed for me. I might try the Xilinx
tools, see if I have better luck with them.

I've worked with Max +II. Debugging in VHDL is built in. ASSERT is a
great tool. Waveforms are for user exploration when a bug is found.


Hmm.. I never saw it. On the other hand : That was 15 years ago.

Quote:
I was trying to point out there is a difference between getting
something to work, and actually understanding it. I failed at that
:)

I've seen that many times. I've even done it when required. Sometimes
you don't have the time to "understand" something if you just need a
simple fix.


I personally don't like that myself.

Quote:
BTW, I can't write PHP code. I don't even know what it is, so obviously
I'm not a monkey. Wink


Advise : Keep it that way :)


Igmar

Igmar Palsenberg
Guest

Thu Nov 12, 2015 7:10 pm   



Quote:
Datastructures come at a price. In software the're cheap, in hardware
the're less cheap. I need to think harder in VHDL about the structure
in general. I find myself far less limited in software (which is also
a potential problem, if you ask me)

I use data structures often in hardware, RAM, FIFO, stacks, arrays, etc.


Is that always synthesizable ?

Quote:
With software, you attach a debugger, and you can step through.
With VHDL, it's not that simple. So yes, I call this a different
mindset. If you think like a software programmer, you'll sooner
or later end up with a non-working, hard to debug prototype.

So you don't use the debugger to set breakpoints and step through
complex RTL? I guess maybe not if you code too close to the edif.

I did that on old Altera software. I failed at the latest version,
still need to look into that. In IntelliJ, it just attach and it
works (c).

Been developing FPGAs in VHDL like SW (enlightened by digital HW
circuit design experience) for 20+ years now. Have fewer problems
than when I tried to code netlists, doing the synthesis tool's job
for it. Sure it's not _exactly_ like SW, but many, many principles
of SW development are highly applicable to RTL.

True. I have 20+ in software, not in hardware. Getting up-to-speed on
VHDL again, which I last used at the university (that was 15 years
ago).

Any questions or issues? I think the hard part of VHDL is the strong
typing which is very similar to Ada and that is no longer hard to me so
it's all easy other than dealing with my requirements for the problem.


I'm used to languages with strong typing. I consider that a big plus myself, especially if you have a decent compiler that warns you when things look weird.

Quote:
In what sense ? Cutting it up in the right modules you mean ? I
especially found the VHDL variable vs signals confusing, and that
fact that it looks sequential, but isn't.

Any time you need to break a problem down to parallel tasks in software
it gets *much* more difficult. In VHDL this is not so much an issue.

The sequential part of VHDL (processes) are *exactly* like software when
you use variables. Signals are only different in that they are not
updated until the process stops. This is because of the fact that
signals are intended to model hardware with delays. So all signal
assignments are made with a delta delay as a minimum which is zero time
(think infinitesimal in math) and so won't happen until the process
ends. All statements in a process happen without time advancing, even
delta time.


Clear. I find debugging programs with a large number of thread a huge PITA. Is something goes wrong, it's sometimes nearly impossible to trace, especially since debuggers change behaviour (read : timing).

Quote:
I'm still struggling testing in VHDL. With software, I'm more
confortable : Junit, gtest, mockito, pick one or combine them. That's
getting harder in the modern async works : Akka for example is
message based, high-parallel.

I guess it has been awhile since I've done C development. I've never
heard of these tools. Mostly my software is done in Forth.


I've never done that. Only C, C++, Pascal, PHP, Java, Scala, Python and bash.

Quote:
I'm looking at vunit for VHDL at the moment, but it's still a bit
confusing : Waveform in, waveform out. With software it's value in,
value out.

VHDL has built in testing tools. ASSERT statements are how I do it.
There are other features provided by system Verilog that are even
fancier I hear. Even so, it's not about waveforms really. Its about
inputs and outputs. VHDL describes the inputs. VHDL verifies the
outputs. Waveforms are for viewing by the user when you have a problem.


Well, take for example the LD A, 0xFF Z80 instruction. That roughly does :

1) Fetch instruction byte from PC and increase PC
2) Fetch operands from PC, and increase PC
3) Move operand to A register
4) Increase PC

How do you test that ? You also want to test timing, since on a real Z80, this instruction takes a fixed amount of time (no pipeline, no cache, no prefetching, no nothing).

I would say confirm each step, but I'm still working that out.


Regards,


Igmar

rickman
Guest

Thu Nov 12, 2015 11:32 pm   



On 11/12/2015 2:36 AM, Igmar Palsenberg wrote:
Quote:
Op dinsdag 10 november 2015 04:04:31 UTC+1 schreef Andy:
On Monday, November 9, 2015 at 5:50:51 AM UTC-6,
igmar.pa...@boostermedia.com wrote:
It's a whole different thing, assuming the end result ends up on
a FPGA. Software is sequenced, around datastructures. VHDL is not
sequenced, and doesn't have thing software has : Lock issues,
memory alignment issues, etc.

Really? You think a modern SW compiler doesn't tweak your sequence
to take advantage of the processor's capabilities. Whether it's SW
or HW: coder, know thy compiler!

Sure.

And who says data structures are exclusive to SW? Oh, you mean they
aren't > available in Verilog? Use a better language!

Datastructures come at a price. In software the're cheap, in hardware
the're less cheap. I need to think harder in VHDL about the structure
in general. I find myself far less limited in software (which is also
a potential problem, if you ask me)


I use data structures often in hardware, RAM, FIFO, stacks, arrays, etc.


Quote:
With software, you attach a debugger, and you can step through.
With VHDL, it's not that simple. So yes, I call this a different
mindset. If you think like a software programmer, you'll sooner
or later end up with a non-working, hard to debug prototype.

So you don't use the debugger to set breakpoints and step through
complex RTL? I guess maybe not if you code too close to the edif.

I did that on old Altera software. I failed at the latest version,
still need to look into that. In IntelliJ, it just attach and it
works (c).

Been developing FPGAs in VHDL like SW (enlightened by digital HW
circuit design experience) for 20+ years now. Have fewer problems
than when I tried to code netlists, doing the synthesis tool's job
for it. Sure it's not _exactly_ like SW, but many, many principles
of SW development are highly applicable to RTL.

True. I have 20+ in software, not in hardware. Getting up-to-speed on
VHDL again, which I last used at the university (that was 15 years
ago).


Any questions or issues? I think the hard part of VHDL is the strong
typing which is very similar to Ada and that is no longer hard to me so
it's all easy other than dealing with my requirements for the problem.


Quote:
I doubt that still works for a *very* large design. On software,
the OS handes a lot for you. No cache flushes, no memory
barriers, etc.

I would beg to differ. Very large designs are where SW approaches
make the most sense and benefit. The larger the design (and body of
code), the harder it is to maintain if you don't think about it
like SW.

In what sense ? Cutting it up in the right modules you mean ? I
especially found the VHDL variable vs signals confusing, and that
fact that it looks sequential, but isn't.


Any time you need to break a problem down to parallel tasks in software
it gets *much* more difficult. In VHDL this is not so much an issue.

The sequential part of VHDL (processes) are *exactly* like software when
you use variables. Signals are only different in that they are not
updated until the process stops. This is because of the fact that
signals are intended to model hardware with delays. So all signal
assignments are made with a delta delay as a minimum which is zero time
(think infinitesimal in math) and so won't happen until the process
ends. All statements in a process happen without time advancing, even
delta time.


Quote:
Cache flushes are not unique to SW. The OS is just more SW. So we
need to write a little more code to do that in RTL.

I haven't reached that point yet :)


Can a programmer while VHDL code ? Sure. But there is a huge
different between good and "it works". Every monkey can write PHP
code, but writing good, maintainable code is a different story.

Yes there is a difference between SW and HW, nobody is denying
that. But I've reviewed, maintained, and debugged too many RTL
designs written too close to the netlist level not to recognize the
benefits of SW approach to RTL.

You have to know where to pay attention to the HW (async clock
boundaries are a big chunk). Then handle that close to the HW
level, but encapsulate it into a few reusable entities (like system
calls to the OS in SW) and then concentrate on the function,
throughput and latency of the rest of the design. On a multi-person
team, only one or two need to deal with the low level stuff, the
rest can design at a much higher level, where the behavior of the
code is critical.

I'm still struggling testing in VHDL. With software, I'm more
confortable : Junit, gtest, mockito, pick one or combine them. That's
getting harder in the modern async works : Akka for example is
message based, high-parallel.


I guess it has been awhile since I've done C development. I've never
heard of these tools. Mostly my software is done in Forth.


Quote:
I'm looking at vunit for VHDL at the moment, but it's still a bit
confusing : Waveform in, waveform out. With software it's value in,
value out.


VHDL has built in testing tools. ASSERT statements are how I do it.
There are other features provided by system Verilog that are even
fancier I hear. Even so, it's not about waveforms really. Its about
inputs and outputs. VHDL describes the inputs. VHDL verifies the
outputs. Waveforms are for viewing by the user when you have a problem.

--

Rick

rickman
Guest

Thu Nov 12, 2015 11:40 pm   



On 11/12/2015 2:41 AM, Igmar Palsenberg wrote:
Quote:
Op dinsdag 10 november 2015 09:15:13 UTC+1 schreef rickman:
On 11/9/2015 6:50 AM, igmar.palsenberg_at_boostermedia.com wrote:
On Sunday, November 1, 2015 at 8:27:30 AM UTC+1, rickman wrote:

I think your distinction is pointless. You said "VHDL is a
description, not a program" and I have you an example when this
is not true. End of discussion for me.

Fine. That doesn't mean you're right.

??? You don't make sense. I give you an example of VHDL that is
a program as used everyday and you reject that???


As to the "mindset", there was a software designer who wanted
to code an FPGA in VHDL and came here asking for advice. We
told him about how he needed to adjust his thinking to design
hardware and not code software. I wrote to him personally to
explain why this was important and came close to getting some
consulting time with his firm. In the end his bosses had faith
that he could do a good job and so he wrote the code himself,
without any trouble.

It's a whole different thing, assuming the end result ends up on
a FPGA. Software is sequenced, around datastructures. VHDL is not
sequenced, and doesn't have thing software has : Lock issues,
memory alignment issues, etc.

I don't think you understand VHDL. VHDL has sequential code, that
is what a process it.

But all of t hem run parallel. With software, it's the other way
around.


Processes run in parallel in both VHDL and in software. In software your
process may be *hugely* complex doing many, many things in each one.
Partly that's because there is a huge overhead for setting up and
managing each process in software. In VHDL a process has no overhead in
the implementation. I'm not sure how complex process management is in
simulation. I've not heard it is a problem though. The speed problems in
simulation often come from the data structures. Integers are faster than
std_logic, et. al.


Quote:
With software, you attach a debugger, and you can step through.
With VHDL, it's not that simple. So yes, I call this a different
mindset. If you think like a software programmer, you'll sooner
or later end up with a non-working, hard to debug prototype.

Huh??? I use single stepping with VHDL at times. Normally it
isn't that useful because there is so much parallelism, things tend
to jump around as one process stops and another starts... same as
software on a processor with interrupts or multitasking.

That's also getting more common in software these days. Ever tried
debugging a 1M messages / second Akka application ?

I've used Altera's Max Plus II, that only had waveforms. Hooking a
real simulator up with Quartus failed for me. I might try the Xilinx
tools, see if I have better luck with them.


I've worked with Max +II. Debugging in VHDL is built in. ASSERT is a
great tool. Waveforms are for user exploration when a bug is found.


Quote:
Can a programmer while VHDL code ? Sure. But there is a huge
different between good and "it works". Every monkey can write PHP
code, but writing good, maintainable code is a different story.

I'm not sure what you are going on about. You started by saying
"VHDL is a description, not a program." Now you seem to be
splitting all manner of hairs and calling programmers "monkeys".

I was trying to point out there is a difference between getting
something to work, and actually understanding it. I failed at that
Smile


I've seen that many times. I've even done it when required. Sometimes
you don't have the time to "understand" something if you just need a
simple fix.

BTW, I can't write PHP code. I don't even know what it is, so obviously
I'm not a monkey. ;)

--

Rick

Andy
Guest

Fri Nov 13, 2015 2:06 am   



Data Structures (records, arrays, etc.) can be custom defined, and as long as they boil down to synthesizable types (Boolean, integer, enumerated types, std_logic, etc.) it all synthesizes. But they can sure make passing data around a lot easier.

I took a couple of Ada programming classes shortly after I started using VHDL, and it helped a lot. Just like Ada, VHDL functions and procedures can be defined to perform common functionality (combinatorial) that can be called sequentially, rather than using a separate entity/architecture that must be concurrently instantiated and communicated with. Things like Hamming/ECC encoding/decoding functions are much easier to use than entities to do the same thing. These functions can be defined inside another subprogram, a process, or inside an architecture or a package, depending on how widely they need to be used.

Use variables for data that does not need to leave the process. Then assign signals with the variables to send to another process/entity. That works much better in that the description is then purely sequential, just like SW. You just have to make sure you don't put too much behavior in one cycle of latency.

And if the logic won't meet the clock period, then add a register (a clock cycle of latency in the process behavior) before and/or after the subprogram call and enable retiming optimization.

Subprograms work really well with state machines, since you can call the subprogram right there in the state, rather than setup an interface to some other entity or process. Just remember that VHDL subprograms have no static variables, so if your procedure needs to remember something from one call to the next, it needs to be passed (an inout data structure parameter works well here). Otherwise, if you declare a procedure in a process, anything declared beforehand in the same process is also visible inside the procedure. And signals/ports that are visible to the process are visible inside the procedure too! That can cut down a lot on how much you have to explicitly pass in/out of a procedure with each call. This way, it is easy to describe an entire state machine, in one subprogram.

The trick is, rather than thinking registers with so many gates between them, think in terms of clock cycles of latency (iterations of the clocked process's inherent "forever" loop). Try not to put too much serial work in any one clock cycle. How much is too much depends on the device and the clock rate.

As far as testing, we use a continuous integration flow with Jenkins. Our testbenches are 100% self-checking (waveforms are for debugging only), and use constrained-random stimulus, while monitoring all DUT outputs for comparison in scoreboards with an untimed reference model. Coverage models for the stimulus ensure we cover what we need to cover in terms of functionality. This can all be done in SystemVerilog using UVM, or in VHDL using OSVVM. We do not do unit level testing. We may use test versions of DUT entities to make it easier to get to an internal entity's functionality, but we always use the DUT interface to simplify the stimulus application (drivers) and response capture (monitors). The scoreboards hook up to the monitors, not the DUT, and to the reference model. Monitors can also verify interface protocols, without having to know anything about the stimulus or expected response.

Hope this helps,

Andy

rickman
Guest

Fri Nov 13, 2015 3:45 am   



On 11/12/2015 12:10 PM, Igmar Palsenberg wrote:
Quote:

Datastructures come at a price. In software the're cheap, in hardware
the're less cheap. I need to think harder in VHDL about the structure
in general. I find myself far less limited in software (which is also
a potential problem, if you ask me)

I use data structures often in hardware, RAM, FIFO, stacks, arrays, etc.

Is that always synthesizable ?


They are if you describe them with synthesizable code. There is nothing
special about any of them that a compiler can't understand. It's all
just logic.


Quote:
With software, you attach a debugger, and you can step through.
With VHDL, it's not that simple. So yes, I call this a different
mindset. If you think like a software programmer, you'll sooner
or later end up with a non-working, hard to debug prototype.

So you don't use the debugger to set breakpoints and step through
complex RTL? I guess maybe not if you code too close to the edif.

I did that on old Altera software. I failed at the latest version,
still need to look into that. In IntelliJ, it just attach and it
works (c).

Been developing FPGAs in VHDL like SW (enlightened by digital HW
circuit design experience) for 20+ years now. Have fewer problems
than when I tried to code netlists, doing the synthesis tool's job
for it. Sure it's not _exactly_ like SW, but many, many principles
of SW development are highly applicable to RTL.

True. I have 20+ in software, not in hardware. Getting up-to-speed on
VHDL again, which I last used at the university (that was 15 years
ago).

Any questions or issues? I think the hard part of VHDL is the strong
typing which is very similar to Ada and that is no longer hard to me so
it's all easy other than dealing with my requirements for the problem.

I'm used to languages with strong typing. I consider that a big plus myself, especially if you have a decent compiler that warns you when things look weird.


I like it in some cases, but until more recently it was a PITA to try to
use as it requires a lot more typing. I am will to give Verilog a shot
if I can find a good book.


Quote:
In what sense ? Cutting it up in the right modules you mean ? I
especially found the VHDL variable vs signals confusing, and that
fact that it looks sequential, but isn't.

Any time you need to break a problem down to parallel tasks in software
it gets *much* more difficult. In VHDL this is not so much an issue.

The sequential part of VHDL (processes) are *exactly* like software when
you use variables. Signals are only different in that they are not
updated until the process stops. This is because of the fact that
signals are intended to model hardware with delays. So all signal
assignments are made with a delta delay as a minimum which is zero time
(think infinitesimal in math) and so won't happen until the process
ends. All statements in a process happen without time advancing, even
delta time.

Clear. I find debugging programs with a large number of thread a huge PITA. Is something goes wrong, it's sometimes nearly impossible to trace, especially since debuggers change behaviour (read : timing).


Delta delays get around repeatability issues while Verilog can be a
killer because of them. If you are single stepping to debug code you
are most likely doing it wrong. That is a poor technique in nearly any
language.


Quote:
I'm still struggling testing in VHDL. With software, I'm more
confortable : Junit, gtest, mockito, pick one or combine them. That's
getting harder in the modern async works : Akka for example is
message based, high-parallel.

I guess it has been awhile since I've done C development. I've never
heard of these tools. Mostly my software is done in Forth.

I've never done that. Only C, C++, Pascal, PHP, Java, Scala, Python and bash.

I'm looking at vunit for VHDL at the moment, but it's still a bit
confusing : Waveform in, waveform out. With software it's value in,
value out.

VHDL has built in testing tools. ASSERT statements are how I do it.
There are other features provided by system Verilog that are even
fancier I hear. Even so, it's not about waveforms really. Its about
inputs and outputs. VHDL describes the inputs. VHDL verifies the
outputs. Waveforms are for viewing by the user when you have a problem.

Well, take for example the LD A, 0xFF Z80 instruction. That roughly does :

1) Fetch instruction byte from PC and increase PC
2) Fetch operands from PC, and increase PC
3) Move operand to A register
4) Increase PC

How do you test that ? You also want to test timing, since on a real Z80, this instruction takes a fixed amount of time (no pipeline, no cache, no prefetching, no nothing).

I would say confirm each step, but I'm still working that out.


Again, you only care about inputs and outputs. Make the opcode
available at the last point in time it can be read by the timing spec or
model the memory as its own function (which you then need to verify). I
don't know that the timing of internal events is required other than
clock cycle alignment. Even then it is hard to test internal features
other than functionally. So execute the next instruction to read the A
register and read it out. That also verifies the PC increment. Test it
as you would a Z80 chip.

I believe I have found ways to read internal signals of modules in VHDL.
I think this is a simulator feature rather than a language feature
though. Verilog supports this directly.

What issues are you concerned about?

--

Rick

rickman
Guest

Fri Nov 13, 2015 3:51 am   



On 11/12/2015 12:00 PM, Igmar Palsenberg wrote:
Quote:

Processes run in parallel in both VHDL and in software.

That can only be done if :

a) You have multiple cores / processors


Neither VHDL nor single processors actually run processes in parallel.
The processor is time multiplexed to run one process at a time. But I'm
sure you know that.


> b) You have an OS that supports it

Yeah... so?

> If either of them are not met, it all runs sequential.

So??? Even with multiple processors multiprocessing has all the same
issues.


Quote:
In software your process may be *hugely* complex doing many, many
things in each one. Partly that's because there is a huge overhead
for setting up and managing each process in software. In VHDL a
process has no overhead in the implementation. I'm not sure how
complex process management is in simulation. I've not heard it is a
problem though. The speed problems in simulation often come from
the data structures. Integers are faster than std_logic, et. al.

I don't expect that simulation runs at fullspeed. Similar tools in
software usually also have an overhead.

I've used Altera's Max Plus II, that only had waveforms. Hooking
a real simulator up with Quartus failed for me. I might try the
Xilinx tools, see if I have better luck with them.

I've worked with Max +II. Debugging in VHDL is built in. ASSERT
is a great tool. Waveforms are for user exploration when a bug is
found.

Hmm.. I never saw it. On the other hand : That was 15 years ago.


ASSERT has been part of VHDL from the beginning. Read up on test
benches. Simulating hardware by generating waveforms manually and
looking at the outputs is a PITA.


Quote:
I was trying to point out there is a difference between getting
something to work, and actually understanding it. I failed at
that :)

I've seen that many times. I've even done it when required.
Sometimes you don't have the time to "understand" something if you
just need a simple fix.

I personally don't like that myself.


There are lots of things about work I don't like. But the job is to do
the job, not make myself happy... well, not all the time.


Quote:
BTW, I can't write PHP code. I don't even know what it is, so
obviously I'm not a monkey. ;)

Advise : Keep it that way :)


Igmar



--

Rick

Lars Asplund
Guest

Sun Nov 15, 2015 7:29 pm   



@rickman

Quote:
I'm looking at vunit for VHDL at the moment, but it's still a bit
confusing : Waveform in, waveform out. With software it's value in,
value out.

VHDL has built in testing tools. ASSERT statements are how I do it.


VUnit doesn't replace the assert statement, it builds on top of it. So VUnit starts where plain VHDL test support stops.

Regards,

Lars

Lars Asplund
Guest

Sun Nov 15, 2015 8:57 pm   



@Andy

> As far as testing, we use a continuous integration flow with Jenkins. Our testbenches are 100% self-checking (waveforms are for debugging only), and use constrained-random stimulus, while monitoring all DUT outputs for comparison in scoreboards with an untimed reference model. Coverage models for the stimulus ensure we cover what we need to cover in terms of functionality. This can all be done in SystemVerilog using UVM, or in VHDL using OSVVM. We do not do unit level testing. We may use test versions of DUT entities to make it easier to get to an internal entity's functionality, but we always use the DUT interface to simplify the stimulus application (drivers) and response capture (monitors). The scoreboards hook up to the monitors, not the DUT, and to the reference model. Monitors can also verify interface protocols, without having to know anything about the stimulus or expected response.

When I promote the use of VUnit it's usually very easy when people have a previous experience with unit testing tools for SW. They know what to expect and they know that they want it. It seems to me that you may have such experience but decided to do only top level testing anyway. That makes me a bit curious about the reasons. Are you working as a verification engineer, RTL designer, or both?

Anyway, it might be interesting for you to know that VUnit doesn't know what a unit is, it doesn't care about your test strategy as long as your testbenches are self-checking, and it has support for Jenkins integration. So if you wrap your testbench in this

library vunit_lib;
context vunit_lib.vunit_context;

entity tb_example is
generic (runner_cfg : runner_cfg_t);
end entity;

architecture tb of tb_example is
begin
main : process
begin
test_runner_setup(runner, runner_cfg);

-- Put whatever your "main process" is doing here

test_runner_cleanup(runner); -- Simulation ends here
end process;

-- Put your DUT, scoreboards, monitors, reference models here

end architecture;

and create a python script (run.py) like this

from vunit import VUnit
vu = VUnit.from_argv()
lib = vu.add_library("lib")
lib.add_source_files("*.vhd")

# Create as many libraries as needed and add source files to them

vu.main()

and do

python run.py -x test_report.xml

from the command line you will have something that (assuming you're using ModelSim, Riviera-PRO, Active-HDL or GHDL) compiles your source files in dependency order based on what has been modified. The script then finds and runs your testbench(es) and generates a test report on "Jenkins format"

Regards,

Lars

Igmar Palsenberg
Guest

Mon Nov 16, 2015 8:30 am   



Quote:
I'm used to languages with strong typing. I consider that a big plus myself, especially if you have a decent compiler that warns you when things look weird.

I like it in some cases, but until more recently it was a PITA to try to
use as it requires a lot more typing. I am will to give Verilog a shot
if I can find a good book.


In my experience, a good IDE can help. Sigasi helps a lot, it also has features that at least the Quartus editor doesn't have.

Quote:
In what sense ? Cutting it up in the right modules you mean ? I
especially found the VHDL variable vs signals confusing, and that
fact that it looks sequential, but isn't.

Any time you need to break a problem down to parallel tasks in software
it gets *much* more difficult. In VHDL this is not so much an issue.

The sequential part of VHDL (processes) are *exactly* like software when
you use variables. Signals are only different in that they are not
updated until the process stops. This is because of the fact that
signals are intended to model hardware with delays. So all signal
assignments are made with a delta delay as a minimum which is zero time
(think infinitesimal in math) and so won't happen until the process
ends. All statements in a process happen without time advancing, even
delta time.

Clear. I find debugging programs with a large number of thread a huge PITA. Is something goes wrong, it's sometimes nearly impossible to trace, especially since debuggers change behaviour (read : timing).

Delta delays get around repeatability issues while Verilog can be a
killer because of them. If you are single stepping to debug code you
are most likely doing it wrong. That is a poor technique in nearly any
language.


Personally, I use logging to a file a lot. And breakpoints on certain points, mainly in async code.

Quote:
I'm still struggling testing in VHDL. With software, I'm more
confortable : Junit, gtest, mockito, pick one or combine them. That's
getting harder in the modern async works : Akka for example is
message based, high-parallel.

I guess it has been awhile since I've done C development. I've never
heard of these tools. Mostly my software is done in Forth.

I've never done that. Only C, C++, Pascal, PHP, Java, Scala, Python and bash.

I'm looking at vunit for VHDL at the moment, but it's still a bit
confusing : Waveform in, waveform out. With software it's value in,
value out.

VHDL has built in testing tools. ASSERT statements are how I do it.
There are other features provided by system Verilog that are even
fancier I hear. Even so, it's not about waveforms really. Its about
inputs and outputs. VHDL describes the inputs. VHDL verifies the
outputs. Waveforms are for viewing by the user when you have a problem.

Well, take for example the LD A, 0xFF Z80 instruction. That roughly does :

1) Fetch instruction byte from PC and increase PC
2) Fetch operands from PC, and increase PC
3) Move operand to A register
4) Increase PC

How do you test that ? You also want to test timing, since on a real Z80, this instruction takes a fixed amount of time (no pipeline, no cache, no prefetching, no nothing).

I would say confirm each step, but I'm still working that out.

Again, you only care about inputs and outputs. Make the opcode
available at the last point in time it can be read by the timing spec or
model the memory as its own function (which you then need to verify). I
don't know that the timing of internal events is required other than
clock cycle alignment. Even then it is hard to test internal features
other than functionally. So execute the next instruction to read the A
register and read it out. That also verifies the PC increment. Test it
as you would a Z80 chip.


I'll just start trying. The Z80 is pretty simple, that makes it a lot easier to get started with. Good exercise.

Quote:
I believe I have found ways to read internal signals of modules in VHDL.
I think this is a simulator feature rather than a language feature
though. Verilog supports this directly.

What issues are you concerned about?


I normally test internals (in software, that is), since it will make determining what broke easier then just testing the public interfaces.
I probably just need to get started, and not think about this to much.


Igmar

Goto page Previous  1, 2, 3, 4  Next

elektroda.net NewsGroups Forum Index - VHDL Language - creating program

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map