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

Clock Edge notation

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation

Goto page Previous  1, 2, 3 ... 110, 111, 112, 113  Next

michael6866
Guest

Wed Jun 17, 2015 2:55 am   



On Tuesday, June 16, 2015 at 5:50:37 PM UTC-4, alb wrote:
Quote:
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 Smile

Quote:

[]
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.

Quote:

(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.

Quote:

(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.

Quote:

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.

Quote:

[]
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.

Quote:

Al


Regards,
Michael

alb
Guest

Wed Jun 17, 2015 3:30 am   



Hi Lars,

Lars Asplund <lars.anders.asplund_at_gmail.com> wrote:
Quote:
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 Wink.

Quote:

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 Smile)


Thanks again for the pointer!

Al

alb
Guest

Wed Jun 17, 2015 3:50 am   



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_at_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

[]
Quote:
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).

Quote:
(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.

Quote:
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.

[]
Quote:
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
Guest

Wed Jun 17, 2015 9:16 am   



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
Guest

Fri Jun 19, 2015 4:11 pm   



Hi Lars,

Lars Asplund <lars.anders.asplund_at_gmail.com> wrote:
[]
Quote:
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.

Quote:
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.

Quote:
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 Wink. 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
Guest

Sat Jun 20, 2015 4:48 pm   



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

Quote:
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
Guest

Thu Jul 02, 2015 1:51 am   



On 17/06/2015 01:51, michael6866 wrote:
Quote:
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
Guest

Wed Aug 05, 2015 10:17 pm   



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
Guest

Wed Aug 05, 2015 10:33 pm   



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
Guest

Thu Aug 06, 2015 3:08 am   



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


Guest

Fri Aug 21, 2015 7:33 pm   



On Tuesday, September 17, 2002 at 12:27:21 PM UTC+3, DJohn wrote:
Quote:
Hi all VHDL experts,
Is there any tools which can convert a C\C++ source file to VHDL . For
example If I have a C source code for a MP3 decoder , Can any tool can
convert it into VHDL equivalent. There is some facility in FPGA Advantage to
generate a wrapper VHDL for a C File , what exactly is that ? Does that
mean I can synthesize a C\C++ file by creating a VHDL Wrapper.
Please help


Take a look at Handel-C. All you have to do is to rewrite couple of statements so that Handel-C compiles and generates VHDL, Verilog, EDIF, and SystemC for you. Use Mentor Graphic DK Design Suite 5.

Tomas D.
Guest

Sat Aug 22, 2015 8:40 pm   



<ahmedablak0_at_gmail.com> wrote in message
news:0ae05f82-6d7f-49f9-9b00-1da23034e98c_at_googlegroups.com...
Quote:
On Tuesday, September 17, 2002 at 12:27:21 PM UTC+3, DJohn wrote:
Hi all VHDL experts,
Is there any tools which can convert a C\C++ source file to VHDL . For
example If I have a C source code for a MP3 decoder , Can any tool can
convert it into VHDL equivalent. There is some facility in FPGA Advantage
to
generate a wrapper VHDL for a C File , what exactly is that ? Does that
mean I can synthesize a C\C++ file by creating a VHDL Wrapper.
Please help

Take a look at Handel-C. All you have to do is to rewrite couple of
statements so that Handel-C compiles and generates VHDL, Verilog, EDIF,
and SystemC for you. Use Mentor Graphic DK Design Suite 5.


Why not to have a look at Vivado HLS? Altera also has something, that will
be available soon.

Allan Herriman
Guest

Mon Sep 28, 2015 5:45 pm   



On Sun, 27 Sep 2015 19:24:47 -0700, fl wrote:

Quote:
Hi,

I remember that I see a code writing on part signal with 'not' logic as:


instance_name : complexMul0
port map (
ar => not(ar),
ai => ai,
br => br,
bi => bi,
clk => CK,
pr => pr,
pi => pi);


Today, when I write the above style and simulate with Modelsim, it gives
error:

(vcom-1436) Actual expression (prefix expression) of formal "ar" is not
globally static.



Could you help me on explain what 'globally static' is?
What VHDL standard allow/dis-allow 'not' logic prefix?


Add quotes around the not like this instead:


port map (
ar => "not"(ar),
ai => ai,
br => br,


You are not allowed to use general expressions in a port map, however
you are allowed to use function calls with at most one signal argument.
This allows type conversions, etc. but not general purpose logic
expressions of multiple signals. I'm not sure why they decided on this
limitation.

The "" quotes made a difference by turning an expression (which is
illegal) into a function call (which is legal).

Globally static roughly means that a name can be resolved at elaboration
time. C.f. locally static, which roughly means that a name can be
resolved at compilation time.
If the compiler is saying that something isn't globally static, then it
still can't work out what to do even after elaboration.

I feel that Modelsim could have given a better error message in this case.

Regards,
Allan

HT-Lab
Guest

Mon Sep 28, 2015 7:22 pm   



On 28/09/2015 12:45, Allan Herriman wrote:
Quote:
On Sun, 27 Sep 2015 19:24:47 -0700, fl wrote:

Hi,

I remember that I see a code writing on part signal with 'not' logic as:


instance_name : complexMul0
port map (
ar => not(ar),
ai => ai,
br => br,
bi => bi,
clk => CK,
pr => pr,
pi => pi);


Today, when I write the above style and simulate with Modelsim, it gives
error:

(vcom-1436) Actual expression (prefix expression) of formal "ar" is not
globally static.



Could you help me on explain what 'globally static' is?
What VHDL standard allow/dis-allow 'not' logic prefix?


Add quotes around the not like this instead:


port map (
ar => "not"(ar),
ai => ai,
br => br,


You are not allowed to use general expressions in a port map, however
you are allowed to use function calls with at most one signal argument.
This allows type conversions, etc. but not general purpose logic
expressions of multiple signals. I'm not sure why they decided on this
limitation.

The "" quotes made a difference by turning an expression (which is
illegal) into a function call (which is legal).

Globally static roughly means that a name can be resolved at elaboration
time. C.f. locally static, which roughly means that a name can be
resolved at compilation time.
If the compiler is saying that something isn't globally static, then it
still can't work out what to do even after elaboration.

I feel that Modelsim could have given a better error message in this case.

Just use verror (cmd prompt or modelsim transcript) to get more info:


D:\>verror 1436

vcom Message # 1436:
VHDL 1993 through VHDL 2002 allowed an expression to be associated with
a formal port in a port map as long as the expression was globally
static and the port was of mode IN. VHDL 2008 now allows non-static
expressions as well. Use the -2008 switch to vcom to enable this
feature.
[DOC: IEEE Std 1076-2002 VHDL LRM - 1.1.1.2 Ports]
[DOC: IEEE Std 1076-2008 VHDL LRM - 6.5.6.3 Port clause]

Regards,
Hans
www.ht-lab.com


Quote:
Regards,
Allan


Jim Lewis
Guest

Wed Sep 30, 2015 6:46 am   



Some small clarifications:

1) Type Conversion Functions
Quote:

Between unrelated types. Requires an explicit function.

Example - Unsigned to Integer, to_integer(U)

2) Type Conversions (what many of us also call type casting)
From 1076-2008, Section 9.3.6, p 137
Explicit type conversions are allowed between closely related types. In particular, a type is closely related to itself. Other types are closely related only under the following conditions:
-- Abstract numeric types -- Any abstract numeric type is closely related to any other abstract numeric type.
-- Array types--Two array types are closely related if and only if the types have the same dimensionality and the element types are closely related\

No other types are closely related.

Quote:
Example - Unsigned to signed, signed('0' & X_uv)

3) Type qualifier

Specifies type when unclear. String arrays can be a number of types, so
require a qualifier to indicate the type. There can be multiple
overloaded functions with the same input types but different return
types, again a qualifier is required to resolve the issue.

Example - Z_sv <= A_sv + signed'("1010") ;


4) Automatic Type Conversion:
Two types convert automatically when both are subtypes of the same type. Combine this with every type is a subtype of itself, and you can conclude that two types will convert automatically when one is a subtype of the other.

Hence, std_ulogic automatically converts to std_logic.

Also in VHDL-2008, std_logic_vector is defined as:
subtype std_logic_vector is {resolved} std_ulogic_vector ;

Hence, in VHDL-2008, these two also convert automatically.

This implies that in VHDL-2008 if you have an old package that includes overloading for both std_ulogic_vector and std_logic_vector, you need to remove one of them or it becomes ambiguous.


Quote:

I think this lists the ways that types are converted or indicated.

Just trying to refresh my memory.


The VHDL Tricks of the Trade (from which you borrowed examples) is still available at: http://synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

Jim

Goto page Previous  1, 2, 3 ... 110, 111, 112, 113  Next

elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation

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