Clock Edge notation

On Tuesday, March 15, 1994 at 1:53:36 AM UTC+5:45, Habibie wrote:

Could someone please email me a copy of the above subject? I am relatively
new to VHDL language. I would like to simulate an 8-bit shift register.

Thank you very much.
-habibie@srse.fiu.edu

Note: Sorry for previous wrong post.

you can design shift register in many ways,
1. using for loop
http://appliedelectronicsengineering.blogspot.com/2015/04/using-for-loop-for-4-bit-shift-register_21.html

2. using a straight forward approach

http://appliedelectronicsengineering.blogspot.com/2015/04/straight-forward-way-to-describe-shift.html

and there are also other ways

 

[GaborSzakacs]

ektelcom@gmail.com wrote:
> On Tuesday, March 15, 1994 at 1:53:36 AM UTC+5:45, Habibie wrote:

[snip]

A 21-year-old thread. This must be some sort of record.

--
Gabor

 

10 years later....I am struggling with that problem now. Any ideas since then ?

On Tuesday, February 7, 1995 at 9:52:18 PM UTC+1, Matthew Todd Gavin wrote:

In Synopsys, "component implication" occurs during synthesis, when you map
a function call to a component instantiation. The code below maps the
function call "check_one_count" to the entity one_counter. Whenever the
function is called in the code, the corresponding component is
instantiated.

The problem is this: the entity uses a generic so that its input vector
(vin) can be of any length. When component implication is done, the
inputs to the corresponding function must be of _known_ length, or the
implication will not work. So my function parameter

signal vin: in std_logic_vector;

screws up the component implication. However, there is no way to pass in
the information for the length of vin, if we want to keep the design
generic.

So is it possible to use component implication to imply a component
which has variable-length input/output? Just wondering if anyone had
encountered this besides me.

Thanks,

Matt

-- check if there are exactly c high std_logics in v
function check_one_count
(signal vin: in std_logic_vector; n,c: integer) return std_logic is
-- pragma map_to_entity one_counter
-- pragma return_port_name c_ones
-- contents of this function are ignored but should
-- match the functionality of the module counter
variable count: integer range 0 to vin'length;
begin
count := 0;
for i in vin'range loop
if vin(i) = '1' then
count := count +1;
end if;
end loop;

if (count = c) then
return '1';
else
return '0';
end if;
end;



--
*********************************************************
Matt Gavin BSEE U of Iowa '93
mtgavin@uiuc.edu Go Iowa Hawks!!!!!
http://www.cen.uiuc.edu/~mg12861/matt.html

 

Try taking off your shoes and socks when you count the years That's 20 years on.

Instead of trolling through very old posts you could consider the issue in terms of the modern specification of the the VHDL language (IEEE Std 1076-2008). (At the head post of this thread does stand out like a sore thumb doesn't it?)

Try 4.4 Subprogram instantiation declarations in the standard where you'll find that those function calls can be instantiated providing separation by usage for varying length array parameter arguments. What we used to colloquially refer to as uniquifying. The intended use is for this very purpose.

http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/dta_type_genericity.pdf
VHDL-200x Data Types and Abstractions White Paper 1, Type Genericity
Peter Ashenden

1 Introduction

Reuse of a design unit can be improved by making it applicable in a wider set of contexts, for example, by making it more generic. VHDL currently includes a mechanism, generic constants, that allows components and entities to be parameterized with formal constants. Actual generi c constants are specified when components are instantiated and when entities are bound. The generic constant mechanism is widely used to specify timing parameters and array port bounds, among other things.

In this proposal we extend the generic mechanism of VHDL to improve support for reuse. There are two main aspects to the extension. The first is to allow subprograms and packages to have generic interface clauses. The second is to allow formal types in a generic interface clause, making the generic item reusable for a variety of different types. Formal subprograms and formal packages are also allowed as a corollary to allowing formal type

--

If it's not supported today, it's due to a lack of -2008 support. Complain to your synthesis vendor. It's a lack of love for VHDL on the part of your synthesis vendor. And otherwise you're exhibiting hyperopia, unable to see clearly into the historical record of the more recent past.

 

[alb]

Hi everyeone, last attempt...

I'm cross-posting here from the SystemC Accellera Forum and
comp.arch.fpga since I *hope* I'm going to receive more feedback here
than there.

alb <al.basili@gmail.com> wrote:
[]

I've recently started to wonder what kind of project I can start with
to get my hands on SystemC and TLM. I know there are tons of tutorials,
getting started like materials, open libraries, open platforms and I
believe I can get my head around most of that stuff, but one thing I'd
like to get advice on is how complex should be my first project to make
my learning process more effective.

I've started proposing modelling with SystemC in my group because we
often lack of a tool to explore the bottle neck of our architectures
and realize about it too late down in the development phase. I've got
granted a 30% of my time for the next 6 months to learn SystemC and TLM
and come up with a reasonably shaped showcase.

One of our core challenges is mass storage (for space applications),
therefore I thought about modelling a possible architecture involving
NAND Flash storage handled through some processor and high speed data
link.

Most of the elements of this fictitious architecture are somehow
available on the net and I would have started plugging things together
for a start.

Does this sound too naive, or is this application too complex to be
achievable in such a short time?

One critical element in this task would be to make the management
understand how much they should invest in 'training/learning' before
getting some benefit out of it.

Any pointer/suggestion/comment is highly appreciated,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Brian Drummond]

On Fri, 12 Jun 2015 14:28:29 +0000, alb wrote:

Hi everyeone, last attempt...

I'm cross-posting here from the SystemC Accellera Forum and
comp.arch.fpga since I *hope* I'm going to receive more feedback here
than there.

Since you cross-posted to comp.lang.vhdl, the feedback you might expect
is that AnythingC is likely to be too firmly based on a foundation of
sand, and therefore an unnecessarily difficult road to hardware.

at least that's my opinion, and it's why I do some relatively high level
modelling in VHDL. Anything synthesisable via C is also potentially
synthesisable via VHDL, with less room for compiler-diagnosable errors.
Where this potential isn't translated into practice, we need to nudge the
synth tool vendors a little...

Where VHDL gives up I use a very similar language, but in which I can for
example create arbitrary fixed point types (natively, not via extensions)
write generic algorithms, and instantiate them with both float and these
fixed types to evaluate accuracy, determine the word lengths required,
and so on.

That gives me a sound basis for a trivial port to VHDL.

It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.

Unfortunately this doesn't help you with System-C.
-- Brian

 

[michael6866]

My two cents embedded below with "MK>":

at least that's my opinion, and it's why I do some relatively high level
modelling in VHDL. Anything synthesisable via C is also potentially
synthesisable via VHDL, with less room for compiler-diagnosable errors.
Where this potential isn't translated into practice, we need to nudge the
synth tool vendors a little...

MK> High level synthesis is a trend. Though there is still a long way to go, I believe eventually the design methodology will evolve to HLS just as how GL evolved to RTL. Some major EDA vendors are spending more and more effort on developing HLS tools and some already get proven in real projects (see CtoS / Stratus for example). I'm not saying how good HLS is today, but learning SystemC can definitely give you some fresh ideas on those fancy stuff. Moreover, SystemC is not all about HLS. For examples:
(1) It gives you the ability for fast prototyping / architecture exploring. VHDL doesn't give you all the kits required for System level modeling and the turnaround time for architecture exploring is not short with VHDL.
(2) It has faster simulation speed. Although you can do some high level modeling with VHDL or Verilog, the simulation speed is not as fast as SystemC. We've done some experiments on bringing up Linux on an ARM based SoC in simulation, with models coded up in SystemC and Verilog individually. One big reason is the differences between the simulation engines. The VHDL simulation engine almost has a fixed scheduling semantics and accuracy. In general it cannot give you "coarse granularity" type of simulation (it may look like, but the engine itself is not).
(3) It's much easier coding virtual platform with SystemC / TLM. Again, taking the Linux bootup example and consider how complex it would be if modeling all components with VHDL. Yes, you can have some IPs to accelerate the work, but it's still much more complex than using C++.
MK> Today it's really a trade-off between accuracy and speed when considering SystemC vs VHDL/Verilog. There are a lot of places where SystemC can help you the most. Also, there is nothing to prevent you from doing mixed simulation. Actually TLM + RTL (some companies call it "soft hybrid") gets pretty popular these days.

Where VHDL gives up I use a very similar language, but in which I can for
example create arbitrary fixed point types (natively, not via extensions)
write generic algorithms, and instantiate them with both float and these
fixed types to evaluate accuracy, determine the word lengths required,
and so on.
MK> Regarding the fixed point types, it's transparent to the user whether or not the type in SystemC is native. For generic programming there is no reason why SystemC cannot do it - it's C++ essentially therefore it comes with the best GP tool kits.

It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.
MK> Design-by-contract is also achievable in C++ (although may not be that attractive). For example, the Contract++ is already adopted by Boost. Again SystemC itself is just a C++ library and there is nothing to prevent you from using other C++ libraries.

 

[alb]

Hi Brian,

Brian Drummond <brian@shapes.demon.co.uk> wrote:

I'm cross-posting here from the SystemC Accellera Forum and
comp.arch.fpga since I *hope* I'm going to receive more feedback here
than there.

Since you cross-posted to comp.lang.vhdl, the feedback you might expect
is that AnythingC is likely to be too firmly based on a foundation of
sand, and therefore an unnecessarily difficult road to hardware.

Uhm, I'm not sure I've fully grasped what you wanted to say here. Just
to clarify my intentions, I'm not looking for synthesizable SystemC, I
know enough of VHDL for not needing another language to synthesize what
I want to synthesize.

My aim here is to leverage more the possibility to perform Architecture
exploration. While deciding where to cut the system in pieces you
dramatically impose constraints that might be turning into bottlenecks
and get your project doomed.

[]

Where VHDL gives up I use a very similar language, but in which I can for
example create arbitrary fixed point types (natively, not via extensions)
write generic algorithms, and instantiate them with both float and these
fixed types to evaluate accuracy, determine the word lengths required,
and so on.

What kind of language are you referring to?

That gives me a sound basis for a trivial port to VHDL.

It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.

Designing by contract is a paradigm, you can build it in assembler or in
any other language. Some of them support it natively, some others
through a set of libraries, but the bottom line is still the same.

Even if a bit OT, here a nice link (http://dbc.rubyforge.org/) about a
ruby utility to parse contracts written in C comments and generate the
necessary code compliant to the Design by Contract paradigm.

> Unfortunately this doesn't help you with System-C.

Discussing always helps, in one way or another!

Al

 

[Lars Asplund]

Hi Al,

If the lack of TLM in VHDL is your only reason for looking at other languages I recommend that you have a look at the open source com mechanism that was added to VUnit a month ago. It implements high-level message passing for VHDL which you need to do TLM. I should probably describe com in a post of its own but here are some pointers

The user guide for com can be found at https://github.com/LarsAsplund/vunit/blob/master/vhdl/com/user_guide.md
and a testbench example is found at https://github.com/LarsAsplund/vunit/tree/master/examples/com. Com was developed by a number of VUnit community members. We took our private code and ideas, improved on that, and came up with the solution that you can download. Everything was done in the open so if you want to follow the discussion you can have a look at this thread https://github.com/LarsAsplund/vunit/issues/23. Com is a separate module in the VUnit project so it can be used standalone (but we recommend you to use VUnit anyway )

 

[michael6866]

On Tuesday, June 16, 2015 at 5:50:37 PM UTC-4, alb wrote:

I suggest for the next time you follow some simple quoting rules. Please
see here for a nice guideline:
http://linux.sgms-centre.com/misc/netiquette.php#quoting
Sorry I'm used to the embedded style as that's the one I used at work. Hopefully I'll get it right this time

[]
MK> High level synthesis is a trend. Though there is still a long way
to go, I believe eventually the design methodology will evolve to HLS
just as how GL evolved to RTL. Some major EDA vendors are spending
more and more effort on developing HLS tools and some already get
proven in real projects (see CtoS / Stratus for example). I'm not
saying how good HLS is today, but learning SystemC can definitely give
you some fresh ideas on those fancy stuff. Moreover, SystemC is not
all about HLS. For examples:

I'm not interested at the moment to HLS and even less to the
synthesizable subsets of SystemC. I'm more into system architecture and
performance analysis.
Understood. I was replying to Brian. The point is HLS is a powerful technology and it will thrive soon.

(2) It has faster simulation speed. []

Beaware of simulation speed comparisons. If you minimize the amount of
signals and maximize the number of variables, you should be getting a
very nice improve (both in maintainability and interoperability with
other models).
Agree. However even with the same magnitude of signals / variables, SystemC is still much faster. As I mentioned this is because the way the RTL simulation engine works is different than the SystemC kernel.

(3) It's much easier coding virtual platform with SystemC / TLM.
[]

I agree, the main reason is to still learn a new language, so that I can
'talk' more clearly! A model is also a type of executable specification,
which in my type of environment is rarely implemented, but huge benefits
would arise whenever is done.
You're talking about golden reference. In that case there are many choices besides SystemC. Of course SystemC is among the best so it's well worth learning.

MK> Today it's really a trade-off between accuracy and speed when
considering SystemC vs VHDL/Verilog. There are a lot of places where
SystemC can help you the most. Also, there is nothing to prevent you
from doing mixed simulation. Actually TLM + RTL (some companies call
it "soft hybrid") gets pretty popular these days.

You also need to take into account another factor: model availability.
The amount of effort to write a simple model in VHDL vs SystemC is
certainly not measureable though, therefore often forgotten.
Agree. However number of SystemC IP is much less than the RTL one today. The good thing is many companies are starting on the former.

[]
It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.

MK> Design-by-contract is also achievable in C++ (although may not be
that attractive). For example, the Contract++ is already adopted by
Boost. Again SystemC itself is just a C++ library and there is nothing
to prevent you from using other C++ libraries.

There exist a ruby utility since more than 10 years
(http://www.onlamp.com/pub/a/onlamp/2004/10/28/design_by_contract_in_c.html),
which inserts C code starting from some markup in the comments. I've
never used it but seems to me pretty well done.
Thanks for the Info. However I don't use design by contract. My reply was merely to point out it's achievable in C++ world.

Al

Regards,
Michael

 

[michael6866]

On Tuesday, June 16, 2015 at 5:50:37 PM UTC-4, alb wrote:

I suggest for the next time you follow some simple quoting rules. Please
see here for a nice guideline:
http://linux.sgms-centre.com/misc/netiquette.php#quoting

Sorry I'm used to the embedded style as that's the one I used at work. Hopefully I'll get it right this time

[]
MK> High level synthesis is a trend. Though there is still a long way
to go, I believe eventually the design methodology will evolve to HLS
just as how GL evolved to RTL. Some major EDA vendors are spending
more and more effort on developing HLS tools and some already get
proven in real projects (see CtoS / Stratus for example). I'm not
saying how good HLS is today, but learning SystemC can definitely give
you some fresh ideas on those fancy stuff. Moreover, SystemC is not
all about HLS. For examples:

I'm not interested at the moment to HLS and even less to the
synthesizable subsets of SystemC. I'm more into system architecture and
performance analysis.

Understood. I was replying to Brian. The point is HLS is a powerful technology and it will thrive soon.

(2) It has faster simulation speed. []

Beaware of simulation speed comparisons. If you minimize the amount of
signals and maximize the number of variables, you should be getting a
very nice improve (both in maintainability and interoperability with
other models).

Agree. However even with the same magnitude of signals / variables, SystemC is still much faster. As I mentioned this is because the way the RTL simulation engine works is different than the SystemC kernel.

(3) It's much easier coding virtual platform with SystemC / TLM.
[]

I agree, the main reason is to still learn a new language, so that I can
'talk' more clearly! A model is also a type of executable specification,
which in my type of environment is rarely implemented, but huge benefits
would arise whenever is done.

You're talking about golden reference. In that case there are many choices besides SystemC. Of course SystemC is among the best so it's well worth learning.

MK> Today it's really a trade-off between accuracy and speed when
considering SystemC vs VHDL/Verilog. There are a lot of places where
SystemC can help you the most. Also, there is nothing to prevent you
from doing mixed simulation. Actually TLM + RTL (some companies call
it "soft hybrid") gets pretty popular these days.

You also need to take into account another factor: model availability.
The amount of effort to write a simple model in VHDL vs SystemC is
certainly not measureable though, therefore often forgotten.

Agree. However number of SystemC IP is much less than the RTL one today. The good thing is many companies are starting on the former.

[]
It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.

MK> Design-by-contract is also achievable in C++ (although may not be
that attractive). For example, the Contract++ is already adopted by
Boost. Again SystemC itself is just a C++ library and there is nothing
to prevent you from using other C++ libraries.

There exist a ruby utility since more than 10 years
(http://www.onlamp.com/pub/a/onlamp/2004/10/28/design_by_contract_in_c.html),
which inserts C code starting from some markup in the comments. I've
never used it but seems to me pretty well done.

Thanks for the Info. However I don't use design by contract. My reply was merely to point out it's achievable in C++ world.

Al

Regards,
Michael

 

[alb]

Hi Lars,

Lars Asplund <lars.anders.asplund@gmail.com> wrote:

If the lack of TLM in VHDL is your only reason for looking at other
languages I recommend that you have a look at the open source com
mechanism that was added to VUnit a month ago. It implements
high-level message passing for VHDL which you need to do TLM. I should
probably describe com in a post of its own but here are some pointers.

Thanks for the pointers! While some level of modeling can be done in
VHDL, and maybe should be done at that level, you certainly do not want
to venture with it when you're facing multiple cores/interfaces
interacting with each other.

SystemC has been conceived for modeling and especially for providing a
simulation platform to run a real algorithm on top, while still
permitting performance analysis and architectural exploration. Sure, I
can change the size of the bus in my VHDL model and get to the same
results, but I suppose it's more efficient to use SystemC rather than
VHDL (and believe me, I'm a big fan of VHDL!).

On top of it, why using the same language when you can learn a new one?
There are potentially new paradigms at your disposal and enriching your
vocabulary would only help your reasoning ;-).

The user guide for com can be found at
https://github.com/LarsAsplund/vunit/blob/master/vhdl/com/user_guide.md
and a testbench example is found at
https://github.com/LarsAsplund/vunit/tree/master/examples/com. Com was
developed by a number of VUnit community members. We took our private
code and ideas, improved on that, and came up with the solution that
you can download. Everything was done in the open so if you want to
follow the discussion you can have a look at this thread
https://github.com/LarsAsplund/vunit/issues/23. Com is a separate
module in the VUnit project so it can be used standalone (but we
recommend you to use VUnit anyway )

Thanks again for the pointer!

Al

 

[alb]

Hi Michael, I was about to post a reply yesterday when my computer
crashed and I lost everything, that's why it took me more than foreseen
to shape a followup to your post. Please follow inline.

michael6866 <michael6866@gmail.com> wrote:
> My two cents embedded below with "MK>":

I suggest for the next time you follow some simple quoting rules. Please
see here for a nice guideline:
http://linux.sgms-centre.com/misc/netiquette.php#quoting

[]

MK> High level synthesis is a trend. Though there is still a long way
to go, I believe eventually the design methodology will evolve to HLS
just as how GL evolved to RTL. Some major EDA vendors are spending
more and more effort on developing HLS tools and some already get
proven in real projects (see CtoS / Stratus for example). I'm not
saying how good HLS is today, but learning SystemC can definitely give
you some fresh ideas on those fancy stuff. Moreover, SystemC is not
all about HLS. For examples:

I'm not interested at the moment to HLS and even less to the
synthesizable subsets of SystemC. I'm more into system architecture and
performance analysis.

> (2) It has faster simulation speed. []

Beaware of simulation speed comparisons. If you minimize the amount of
signals and maximize the number of variables, you should be getting a
very nice improve (both in maintainability and interoperability with
other models).

(3) It's much easier coding virtual platform with SystemC / TLM.
[]

I agree, the main reason is to still learn a new language, so that I can
'talk' more clearly! A model is also a type of executable specification,
which in my type of environment is rarely implemented, but huge benefits
would arise whenever is done.

MK> Today it's really a trade-off between accuracy and speed when
considering SystemC vs VHDL/Verilog. There are a lot of places where
SystemC can help you the most. Also, there is nothing to prevent you
from doing mixed simulation. Actually TLM + RTL (some companies call
it "soft hybrid") gets pretty popular these days.

You also need to take into account another factor: model availability.
The amount of effort to write a simple model in VHDL vs SystemC is
certainly not measureable though, therefore often forgotten.

[]

It also gives me full object orientation where I need it, and access via
import mechanisms to anything written in C or C++. Design-by-contract via
pre/postconditions is also available though I haven't used that yet, nor
have I used the formal proof extensions, but these are much more
attractive options to me than anything I've seen offered by System-C.

MK> Design-by-contract is also achievable in C++ (although may not be
that attractive). For example, the Contract++ is already adopted by
Boost. Again SystemC itself is just a C++ library and there is nothing
to prevent you from using other C++ libraries.

There exist a ruby utility since more than 10 years
(http://www.onlamp.com/pub/a/onlamp/2004/10/28/design_by_contract_in_c.html),
which inserts C code starting from some markup in the comments. I've
never used it but seems to me pretty well done.

Al

 

[Lars Asplund]

Hi Al,

Thanks for sharing. The reason for me asking is that the message passing in VUnit wasn't developed to support TLM for hardware out of the box. It was developed to enable high-level communication within testbenches, not within the DUT. In that context we want to be focused on the information to exchange and with whom. We don't want to know where our counterparts are located, we don't want communication to take time, we don't want to be exposed to FIFOs limiting the communication capacity and so on. These are things that becomes more interesting when you want to model hardware and it can be added as an extra layer of functionality on top of the "pure" message passing. Since you're working across the range of abstraction levels I'm interested to see under what circumstances, if any, you see use cases for TLM in VHDL.

A bit off topic...

/Lars

 

[alb]

Hi Lars,

Lars Asplund <lars.anders.asplund@gmail.com> wrote:
[]

Thanks for sharing. The reason for me asking is that the message
passing in VUnit wasn't developed to support TLM for hardware out of
the box. It was developed to enable high-level communication within
testbenches, not within the DUT.

I'm not sure to which question or statement you're referring to.

I think DUT need to be described with purely non-synthesizable construct
that focus on the architecture rather than the details. This model can
leverage the TLM message passing mechanism in order to do architecture
exploration and allow to build a verification environment.

Unfortunately this step is too often tossed away of the development plan
to only find ourselves in the weeds too many weeks/months later.

Non-synthesizable VHDL is also poorly taught and valued in undergraduate
courses, the focus on the synthesizable subset of the language casts
some habits into designers that are hard to break and lead eventually to
poor perfomance.

I've seen professionals writing testbenches as if they were to be
synthesized! That's not what the language allows us to do. Likely some
libraries and utilities are popping out and maybe help designers to
write better simulation environments.

In that context we want to be focused
on the information to exchange and with whom. We don't want to know
where our counterparts are located, we don't want communication to
take time, we don't want to be exposed to FIFOs limiting the
communication capacity and so on. These are things that becomes more
interesting when you want to model hardware and it can be added as an
extra layer of functionality on top of the "pure" message passing.

Message passing is an extremely important concept that is often
forgotten when you are head down hitting your keyboard to write RTL.
Building a function thinking in terms of messages passed from one point
to another is a powerful tool that allows to see where these messages
interact in the datapath and may help find a better way to avoid
bottlenecks.

I want/need to focus on the 'what's going on' part of the game, rather
than on 'how is going on' and FWIK this is what a 'tool' like
SystemC/TLM has been thought for. I believe I can do the same in
non-synthesizable VHDL but I'd like to explore new constructs and see
what suits the best for what.

Since you're working across the range of abstraction levels I'm
interested to see under what circumstances, if any, you see use cases
for TLM in VHDL.

I think about TLM as a methodology rather than a library and what is
important here is shifting approach according to the need. I know of a
tool (TauhopHLS) which converts vhdl-2008 syntax into synthesizable
vhdl-93, with the promise to bridge the gap between an high level
modeling and the registers ticking. I haven't used the tool (yet), but
'standardizing' designs through a set of high level constructs is not
less than building a libc for hardware! Why would you want to take care
about the bits and pieces that happen behind the scenes? Let someone
else optimize it for you, someone who knows the target technology better
than you can possibly know and focus on the application *you* need to
design.

Resources in the FPGAs are increasing at an incredible pace and yet
there are tons of designers that meticoulously care about the registers
and the gates...on a million gates device? Good luck!

Anyway, we definitely drifted OT here, but I'll venture in learning
SystemC/TLM and see where this path will lead me to ;-). Alan Fitch, who
maybe listening here, have pointed me to an incredibly well done
tutorial by embecosm: http://www.embecosm.com/resources/appnotes/#EAN1.
I'll see where I'll find myself in the end.

Al

 

[Lars Asplund]

Den fredag 19 juni 2015 kl. 12:11:56 UTC+2 skrev alb:
Hi Al,

Thanks for sharing. The reason for me asking is that the message
passing in VUnit wasn't developed to support TLM for hardware out of
the box. It was developed to enable high-level communication within
testbenches, not within the DUT.

I'm not sure to which question or statement you're referring to.

What I'm saying is that message passing in VUnit wasn't developed to support design space exploration of the to be synthesized hardware. It was developed to have message passing which takes no time and has no capacity limitations which is very useful within testbenches (outside of the DUT). When we did this I recognized that it can be used for your purposes as well if support for those delay and capacity limitations is added. We decided to leave this for the future to see what users want and when I saw this thread I started to wonder if the future is here.

Anyway, you have time to learn something new so you should. Good luck!

/Lars

 

[HT-Lab]

On 17/06/2015 01:51, michael6866 wrote:

On Tuesday, June 16, 2015 at 5:50:37 PM UTC-4, alb wrote:
...snip


(2) It has faster simulation speed. []

Beaware of simulation speed comparisons. If you minimize the amount of
signals and maximize the number of variables, you should be getting a
very nice improve (both in maintainability and interoperability with
other models).
Agree. However even with the same magnitude of signals / variables, SystemC is still much faster. As I mentioned this is because the way the RTL simulation engine works is different than the SystemC kernel.

It is not, from what I understand the SystemC kernel is very close to
the one used in VHDL. For this reason it is very easy for a VHDL
engineer to pick up SystemC (leaving the C++ horrors aside) as you get
the same signal/variables/process goodness. I am so happy the OSCI
developers didn't pick the blocking and unblocking spaghetti model ;-)

I am also pretty sure you are incorrect regarding the speed of models
with the same number of events. Most vendors (re)use the OSCI reference
simulator and although they might have tweaked it a bit it is still
miles away from a modern VHDL kernel you find in say
Modelsim/Riviera/NCSIM/etc. I have done a simple test were I converted a
few simple RTL VHDL models into SystemC (same number of events, same
architecture) and compared the speed. The VHDL models were roughly 2-3x
faster than SystemC both executed on Modelsim.

Regards,
Hans
www-ht-lab.com

 

[Jezmo]

Its the usual fantasy of the open source community that somehow open source tools will open up unheard of advantages because you can fiddle with and probably break the sourcecode. It never happensin real life and like rick iI have yet to see anything obviously broken in the code produced by major vendors and I have no desire to spend months working out the inner workings of a program which has taken hundreds of man years to write.

 

[Jezmo]

As a working engineer ive got designs to produce, my boss would not be pleased if I told him I was going to spend a month adding functionality to a logic synthesis tool. Most FOSS advocates are software kiddies who have never grown up and hang on every word of people such as Stallman

 

[rickman]

On 8/5/2015 4:33 PM, Jezmo wrote:
> As a working engineer ive got designs to produce, my boss would not be pleased if I told him I was going to spend a month adding functionality to a logic synthesis tool. Most FOSS advocates are software kiddies who have never grown up and hang on every word of people such as Stallman

I'm not sure I would make any statement like that. I think FOSS is more
important or at least more useful in software because it can be a
complete package. With hardware it is a bit harder because the hardware
itself can be difficult to make accessible in the same way.

Regardless, I am not trying to argue with anyone. I was asking for a
clarification of what people expect from having open source tools.

--

Rick