Re: [Ghdl-discuss] entity instantiation

[David Koontz]

> On May 13, 2017, at 11:48 PM, Тихомиров Валентин  wrote:
> 
> The command is
>  
> ghdl -a adder.vhdl && ghdl --elab-run adder_tb
>  
> and it analyzes the correct file which I prove by injecting a terrible 
> syntactic error and it fails to parse.

In addition to a selected or directly visible named entity with the same simple 
name as the entity that has been analyzed into either the same working library 
or a reference library there's something called a default binding indication, 
which requires that the port declarations match formals in the port map and the 
port map obeys semantic rules for association lists.

If this were Stackoverflow someone would pop up and suggest you provide a 
Minimal, Complete, and Verifiable example  
instead of snippets then complain when you can't get a quality answer without 
sufficient information.



> 13.05.2017, 14:38, "Paebbels" :
>> Hello,
>> 
>> have you analyzed adder before that component?
>> Please provide the executed GHDL commands.
>> 
>> Am 13.05.2017 1:34 nachm. schrieb "Тихомиров Валентин" > >:
>> >adder_0: entity work.adder port map (i0 => i0, i1 => i1, ci => ci,
>>  s => s, co => co);
>>  
>> > adder is not directly visible.
>>  
>> Thanks but "work" does not improve anything. I am still getting the same "no 
>> declaration for adder" error.
>> 
>> ___
>> Ghdl-discuss mailing list
>> Ghdl-discuss@gna.org 
>> https://mail.gna.org/listinfo/ghdl-discuss 
>> 
>> 
>> 
>> ,
>> ___
>> Ghdl-discuss mailing list
>> Ghdl-discuss@gna.org 
>> https://mail.gna.org/listinfo/ghdl-discuss 
>> 
> ___
> Ghdl-discuss mailing list
> Ghdl-discuss@gna.org
> https://mail.gna.org/listinfo/ghdl-discuss

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Compile error: actual expression must be globally static

[David Koontz]

> On Nov 12, 2016, at 9:58 AM, Carlos Alberto Ruiz  > wrote:
>  
> Hello Andrey,
>  
> I've changed the code and made it compatible with standard VHDL.
>  
> ---

Non-static expressions as actuals in port map associations is a -2008 feature.

IEEE Std 1076-2008
6.5.6.3 Port clauses 
para 6:

If the actual part of a given association element for a formal port of a block 
is the reserved word inertial followed by an expression, or is an expression 
that is not globally static, then the given association element is equivalent 
to association of the port with an anonymous signal implicitly declared in the 
declarative region that immediately encloses the block. The signal has the same 
subtype as the formal port and is the target of an implicit concurrent signal 
assignment statement of the form

anonymous <= E;

where E is the expression in the actual part of the given association element. 
The concurrent signal assignment statement occurs in the same statement part as 
the block.

 --

The equivalent section in -2000 (-2002 or earlier) is 1.1.1.2 Ports, where 
paragraph 4 specifies an expression must be globally static:

To communicate with other blocks, the ports of a block can be associated with 
signals in the environment in which the block is used. Moreover, the ports of a 
block may be associated with an expression in order to provide these ports with 
constant driving values; such ports must be of mode in. A port is itself a 
signal (see 4.3.1.2); thus, a formal port of a block may be associated as an 
actual with a formal port of an inner block. The port, signal, or expression 
associated with a given formal port is called the actual corresponding to the 
formal port (see 4.3.2.2). The actual, if a port or signal, must be denoted by 
a static name (see 6.1). The actual, if an expression, must be a globally 
static expression (see 7.4).
 --

Also note that with the implicit signal you incur a simulation delta cycle 
delay in the assignment, something to take into account for zero delay modeling.

Also see Peter Ashenden and Jim Lewis's book 'VHDL 2008 Just the New Stuff' 
Chapter 6 Modeling Enhancements, 6.1 Signal Expressions in Port Maps.

I don't believe ghdl supports non-static expressions as actual with --std=08 
(as yet). 

I'd dispute it's any more succinct - although brief, not clearly expressed 
because of the hidden delta cycle delay in the implicitly declared signal 
assignment. 

> El 11-11-2016 15:34, Andrey Gursky escribió:
> 
>> Hi Carlos,
>> 
>> On Tue, 25 Oct 2016 16:39:51 +0200 Carlos Alberto Ruiz wrote:
>> 
>>> Thanks for the response Andrey Gursky. 
>>> 
>>> I use VHDL 2000. Im having errors in a lot of ports. For example: 
>>> 
>>>  signal in_0 : std_logic; 
>>>  signal out_0 : std_logic';
>>> 
>>>  signal out_1 : std_logic';
>>> 
>>>  IP0: ip0 port map (
>>>  input => in_0 & in_0, -- ERROR
>>>  output => out_0
>>>  );
>>> 
>>>  IP1: ip1 port map (
>>>  input => out_0 and out_0, -- ERROR
>>>  output => out_1
>>>  ); 
>>> 
>>> I can´t put expression in ports. Is there any way you could do it? I
>>> have a really big design and is very tedious change everything.
>>> I want to use GHDL with VUNIT, so I would not change compiler.
>> 

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Elapsed time increasing more than exponentially with linear increase in simulation time

[David Koontz]

> On 09 Aug 2016, at 1:00 pm, Thomas Dejanovic  
> wrote:

> I have a simulation sending packets through a system.  It works very
> well until we start to use some Xilinx primitives. If I break the
> system down and leave out the module that has Xilinx primitives, the
> simulation runs at least an order of magnitude faster and elapsed time
> increases linearly with increasing simulation time. Once we
> instantiate code that contains Xilinx primitives, doubling the
> simulation time (i.e. doubling the number of packets sent) increases
> the simulation time by about a factor of 6.
> 
> i.e. - sending 128 packets takes about 2 minutes of sim time. 265 =>
> 12 minutes, 512 packets => ~72 minutes and 1024 packets takes longer
> than I was willing to wait (jobs were killed after running for more
> than 350 minutes).
> 
> So my question is, has anyone else observed this behavior?


An apparent logarithmic increase in simulation time seems related to memory 
leaks. 

There was an issue reported by Adrien Prost-Boucle around 9 March this year. 

https://mail.gna.org/public/ghdl-discuss/2016-03/index.html


That was 'cured' by Tristan's commits c14f262, f4a612 and f1ddf16 around the 
15th of March (SourceTree reports times on this side of the international 
dateline).

https://mail.gna.org/public/ghdl-discuss/2016-03/msg00014.html

> this issue is now fixed by my latest patches.
> There was a threshold effect that prevented memory reuse and therefore
> slowed down simulation.


So the interesting questions become what revision (and potentially build 
date/commit) of ghdl, what platform and what Xilinx primitives/macros (and from 
what tool and version/release) are used when encountering the problem.

Follow that by whether or not you can monitor memory utilization of your 
running ghdl simulation to determine whether or not there is a leak (should you 
be using a later built ghdl than those commits).

Tristan has some Linux releases, llvm and mcode of several dates after the 
patches.

https://github.com/tgingold/ghdl/releases










___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Better way for integer handling in VHDL ?

[David Koontz]

> On 28 Jul 2016, at 2:08 am, Patrick Lehmann  
> wrote:
> 
> Hmmm 9.5
> 
> I must have missed the point that universal_expressions are also bound by 
> "normal" integers/implementation restrictions

It's common believe me.

> But how does it relate to some mailing list replies, where someone stated: 
> it's already possible to define larger integers or physical types, if the 
> tool supports it. But no tool, which I know of, has an INTEGER which is 
> bigger than (1s compl.) 32-bit? Is there some destination between the INTEGER 
> type from STD and the internal biggest supported integer representation?

I used to widely describe VHDL as a skill acquired by the journeyman system. 
VHDL's original masters are no longer practicing and the demand for new 
implementations is low.

When the universal integer is larger than 32 bits and the restriction is 
overlooked by the VHDL journeyman on his way to the proof of mastery - an 
implementation, you can get the mistake. The size of universal integer isn't 
knowable from the VHDL language and reflects something of the programming 
platform used for the implementation. That programming language type may be 
shared with a larger predefined physical type (64 bit TIME). There can also be 
schism - acting on belief or fomenting change.  

Constraints on portability serve as barriers to harm in this case. We used to 
search out these sort of 'synthetic programming' opportunities in VHDL until 
the -1993 revision closed off so many avenues in search of achieving functional 
notation supporting formal notation for hardware description. 

You'd be surprised what you can do with a few semantic restrictions dropped and 
that would be implementation dependent. The VHDL language became less ambiguous 
and incidentally harder to implement while better defined for portability.
   
There are no checklists, or publicly available accurate and complete test 
suites. The LRM has to be embraced with the fervor of a lawyer studying the 
law. There are no authoritative works the equivalent of a 'Patry on Copyrights' 
teaching implementation, the market for perspective masters is too small. As in 
law every word in the standard describing VHDL has meaning and understanding 
that meaning of a collection of these words means understanding the words and 
implications. 

It's basically epistemology. And we do see the collision of belief and 
knowledge. Your reference to 'someone' doesn't pass epistemological muster, do 
you have citations and text? Are those authoritative?  And you can still get 
someone popping out of the bushes with a  copy of the standard ready to 
demonstrate otherwise. Likewise your authority can change their tune when their 
knowledge (awareness) of the standard evolves. They maybe promoting change 
intentionally or simply be mistaken. Their writing may be taken out of context, 
a strawman...

The reason no one has a bigger INTEGER is because none of the synthesis tools 
support it. That should demonstrate that changes to the standard need consensus 
of all involved as well as questioning the need for bigger integers 
epistemologically. Hopefully separating cold logic from hot politics (or market 
share).



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Better way for integer handling in VHDL ?

[David Koontz]

> On 27 Jul 2016, at 7:29 pm, Patrick Lehmann  
> wrote:
> 
> The languages doesn't forbid large integers, but must tools are restricted
> in handling such large literals/signals/variables. You could create your own
> "64 bit" integer:

It's safer to say that the language does not permit integer types with a range 
wider than the range of the widest integer defined by the implementation. (And 
that would be in package STANDARD).

> constant BITS : positive := 64;
> type long is range -2**(BITS-1)+1 to 2**(BITS-1) - 1;


-  2 ** ( BITS - 1 ) + 1

The "-" is the unary operator negation.

Left to right with "**", parentheses enclosing it's right operand.

The right operand is type INTEGER (POSITIVE is a subtype). 
The left operand is an abstract literal an integer literal (type 
universal_integer) the result type is the same as the left (IEEE Std 1076-2008 
9.2.8 Miscellaneous operators) and that's universal_integer.

Now for the kicker:

9.5 Universal expressions

A universal_expression is either an expression that delivers a result of type 
universal_integer or one that delivers a result of type universal_real.

 ...

For the evaluation of an operation of a universal expression, the following 
rules apply. If the result is of type universal_integer, then the values of the 
operands and the result shall lie within the range of the integer type with the 
widest range provided by the implementation, excluding type universal_integer 
itself. ...

 -- 

(And that means the result of the exponentiation operator shall lie within the 
range of the integer type INTEGER. 2 ** (64 - 1) is outside the range of type 
INTEGER.)

There's only one type in a VHDL with a 32 bit INTEGER that can have a value 
outside the range of INTEGER  and that's type TIME, a scalar type but not an 
integer type. You cannot use it's 'LEFT or 'RIGHT  or 'LOW and 'HIGH because 
the their values are same type as the prefix TIME. 

And no you can't use TIME'POS(T'RIGHT), it's a function that returns a 
universal_integer (an expression of type universal_integer) and is a is limited 
by 9.5 as well.

If you were to try the expression TIME'LEFT / 1 fs the result would be type 
universal_integer (See 9.2.7, the second table with physical type operands for 
"/"). That's limited by 9.5 as well.

Trying to express the bounds  with literals:

range -9223372036854775808 to 9223372036854775807 

An integer literal is an abstract literal (a numeric literal). It's value is 
realized by a basic operation (See 5.1).  It's an expression (9.1, primary - 
literal, 9.3.2 literal, numeric_literal).

And back to 5.1:

A type is characterized by a set of values and a set of operations. The set of 
operations of a type includes the explicitly declared subprograms that have a 
parameter or result of the type. The remaining operations of a type are the 
basic operations and the predefined operations (see 5.2.6, 5.3.2.4, 5.4.3, and 
5.5.2). ...
 --

So a basic operation is an operation of a type. And 5.2.3.1 

Integer literals are the literals of an anonymous predefined type that is 
called universal_integer in this standard. Other integer types have no 
literals. However, for each integer type there exists an implicit conversion 
that converts a value of type universal_integer into the corresponding value 
(if any) of the integer type (see 9.3.6).
 --

Which gets us back to our kicker in 9.5.

You can demonstrate this in ghdl with the above range:

 ghdl -a fum.vhdl
fum.vhdl:6:45: literal beyond integer bounds
ghdl: compilation error

Your long declaration gives:

ghdl -a fum.vhdl
fum.vhdl:4:26:warning: arithmetic overflow in static expression
fum.vhdl:4:43:warning: arithmetic overflow in static expression
fum.vhdl:4:36: overflow in left bound
fum.vhdl:4:54: overflow in right bound

And the source:
 --

package fum is
constant BITS : positive := 64;
type long is range -2**(BITS-1)+1 to 2**(BITS-1) - 1;

-- type myint is range -9223372036854775808 to 9223372036854775807;
end package;
 --

(line 1 is empty).


You can't define an INTEGER with a width greater than type INTEGER (which is 
required to include the range –2147483647 to +2147483647. (5.2.3.2).

ghdl --disp-standard reports:

type integer is range -2147483648 to 2147483647;
 ...
type time is range -9223372036854775808 fs to 9223372036854775807 fs ...

The restriction is that you can't define an integer type outside the range of 
the largest integer type defined by the implementation, which is found in 
package STANDARD and is type INTEGER.

There is a bit about restricting the range of integer types comes from 5.2.3.1:

An implementation may restrict the bounds of the range constraint of integer 
types other than type universal_integer. However, an implementation shall allow 
the declaration of any integer type whose range is wholly contained within the 
bounds –2147483647 and +2147483647 inclusive.
 --

Unfortunately it's not the implementation that's 

Re: [Ghdl-discuss] Huge simulation speed slowdown

[David Koontz]

I had gone through and characterized your design looking for anomalies, also 
looked at the previous one you had reported and Tristan responded to about 
ghdl's slow-ish concatenation. The idea was to look for things before the 
effort of profiling.

I found those 5,204 input vectors (bytes) that weren't finishing loading in any 
reasonable time would take 5-6 seconds with another VHDL simulator (not quite 
as feature rich as ghdl) and the entire simulation would take 12 minutes and a 
few seconds (completed successfully, around 784 cycles/second), same platform 
(late 2008 Aluminum Macbook). The idea to see what to expect from ghdl.

As part of the characterization I looked at both versions of the generated 
design:

Design # of "&" operatorsLines of code  stdin port 
width 
  (top.vhd)

vhdl5082 (2014) 9,8229,440  32
vhdl7L5y (2016) 2,474   16,190   8

While the earlier one doesn't look complete by line count you still noticeably 
reduced the number of concatenation operators. I take it that was as a result 
of the repeat function, I didn't really search for the impact of the different 
bus sizes during characterization.

The two assignment statements Tristan notes as large contain 974 of those 
remaining 2,474 concatenation operators between the two of them.  (An editor 
that can count them).

I had  performed various easy experiments like commenting out the write textio 
stuff and determined that wasn't responsible for the slow down nor the memory 
leakage.

Commenting out the two assignments (providing them with a dummy value) gives a 
lot faster simulation - too fast to look for memory leaks, and utterly failing 
the testbench.

It looks like the concatenation performance problem you had originally may be 
responsible in the present model, in a 
poke-the-kerchief-in-your-fist-and-sticks-out-there sort of way. You have fewer 
concatenations but have some big expressions.  

Code generation changes might alleviate the immediate crisis.

It's possible to get rid of the large number of concatenation operators in 
those two statements by producing an extend function to match the repeat 
function:

signal mux_291 : std_logic_vector(40 downto 0);

mux_291 <=
(
  repeat(41, sig_1468) and 
   -- sig_1642(31) & sig_1642(31) & sig_1642(31) & sig_1642(31) & 
sig_1642(31) & 
   -- sig_1642(31) & sig_1642(31) & sig_1642(31) & sig_1642(31) & 
sig_1642) 
  std_logic_vector(resize(signed(sig_1642),41)
-- equivalent
 )
  or
(
  repeat(41, sig_1505) and 
   -- huff_make_dhuff_tb_ac_j(31) & huff_make_dhuff_tb_ac_j(31) & 
   -- huff_make_dhuff_tb_ac_j(31) & huff_make_dhuff_tb_ac_j(31) & 
   -- huff_make_dhuff_tb_ac_j(31) & huff_make_dhuff_tb_ac_j(31) & 
   -- huff_make_dhuff_tb_ac_j(31) & huff_make_dhuff_tb_ac_j(31) & 
   -- huff_make_dhuff_tb_ac_j(31) & huff_make_dhuff_tb_ac_j
  std_logic_vector(resize(signed(huff_make_dhuff_tb_ac_j),41)  
-- equivalent
) 
  or
  ...

A resize type extend function could  take advantage of asssumptions - You don't 
call it when you don't need it, it doesn't clip, the arrays it deals with are 
descending order.. 

> On 15/03/2016, at 1:43 pm, Brian Drummond  wrote:
> 
> On Tue, 2016-03-15 at 00:40 +0100, Adrien Prost-Boucle wrote:
>> Hi,
>>  
>> I had another idea.
>> 
>> Re-evaluating the entire mux expressions is a heavy task.
>> So would it be possible to re-evaluate only the sub-expressions that
>> have changed? Including, for function calls, only those that have no
>> side-effects ("pure" functions), and whose arguments have changed? If
>> such an optimization is possible, it may improve speed for many other
>> designs.



This seems more akin mapping in FPGA's during synthesis where duplicates will 
fall out. 

The shortcoming seems to be in the generated code.

> Seems to me an easy way to do this would be to generate a tree of
> sqrt(N) sized muxes (for a tree of depth 2) then you are evaluating 2
> small muxes instead of one huge one.
> 
> Might be easy to change this part of the code generator to test the
> idea (for muxes of large N) and tune the heuristics (depth, when to
> start splitting muxes) later.

I didn't receive any of Adrien's posts today either after switching email 
accounts for ghdl-discuss.  Turns out gmail had them as SPAM, saw the DKIM 
stuff, marked them as not SPAM. I can't imagine any possible resolution with my 
ISP outsourcing to Yahoo. Gmail has a strong sender address keying, here's 
hoping.

sig_1468 and sig_1505 in the above code snippet are individual decoded selects 

Re: [Ghdl-discuss] Huge simulation speed slowdown (with llvm)

[David Koontz]

> On 10/03/2016, at 10:50 am, Lehmann, Patrick  
> wrote:
> 
> Hello Adrien,
> 
> Can you give some information on your used GHDL installation?
> - version number or source code checkout date
> - backend: gcc, llvm, mcode
> 
> Are you exporting the simulation results as a waveform dump file? E.g. vcd, 
> fst, ghw, ...
> => This has a high performance impact, caused by string operations and file 
> I/O
> 
> What is the used VHDL version?
> 
> Are you running xSim in multi-threaded mode?
> -mt on|off|2...n (it's enabled by default)

For whatever reason I didn't get Adrien's original post. Recovering it from 
ghdl-discuss archives to recover vhdl.tar.gz and running the model shows 
something interesting.

The vector rate is asymptomatic (it gets slower the longer it runs). (OS X 
ghdl-0.33 llvm).

On a Mac (OS X) you can watch the memory utilization climb.

real memory size 163.2 MB around 580 cycles.
 164.6 MB around 780 cycles
 169.5 MB around 1434 cycles

The ghw file progresses in size  1,842,834 bytes after 730 cycles
 1,846,930   after 738
 1,965,714   after 1434

The virtual memory size goes up slowly over time 2.50 GB at 1486 cycles, it was 
2.39 GB at 580 cycles. I'd imagine I'd imagine the simulation might end (550K 
cycles) before running out of memory.

I haven't looked in depth at the model, grep'ing shows no allocation going on.

Where the memory leak is, isn't readily apparent. 

At around 962 cycles it had slowed down to around 3 seconds per two cycles. 5 
seconds by 1350 (This doesn't seem like a malloc artifact, unless there's lots 
of big things being copied, OS X is fairly efficient for small things).

There are oddities in how the code was generated. In jpegfilebuf.vhd for 
instance there's the context clause:

library ieee;
use ieee.std_logic_1164.all;

library ieee;
use ieee.numeric_std.all;

There's also a declaration of to_integer[std_logic_vector return integer] to 
overcome the lack of numeric_std_unsigned (or Synopsys packages). Te intent 
looks to be -93 compatible.

I take it this thing is a jpeg compressor?

1500 cycles or so and got 15020 ns of waveforms which tells us the clock speed 
with out looking. A mere 15 us after quite some realtime.


Without the waveform dump file it slows down asymptomatically as well, just not 
as fast (The curve is offset). The real memory size goes up as does virtual 
memory size.

This is the first sizable simulation in ghdl I can recall seeing with writes to 
standardout showing simulation time slowing. The slowly slower doesn't seem to 
be an OS X job scheduling artifact.

Just saw Jim's reply to Adrien's follow up. I simply don't get email from 
Adrien. That enough to make me switch to gmail for ghdl-discuss. My ISP gave 
email to Yahoo, while you'd expect that to change soon. This looks like Yahoo 
doesn't like his apparently from.

The link to the original problem 
https://mail.gna.org/public/ghdl-discuss/2014-11/msg00064.html 

The models appear highly similar. I'd imagine the problem is related.

> -Original Message-
> From: Ghdl-discuss [mailto:ghdl-discuss-boun...@gna.org] On Behalf Of Adrien 
> Prost-Boucle
> Sent: Wednesday, March 09, 2016 9:38 PM
> To: GHDL discuss list 
> Subject: [Ghdl-discuss] Huge simulation speed slowdown
> 
> Hi,
> 
> I have a VHDL design that GHDL simulates at a speed of only one or 2 clock 
> cycles per second. The same design, same VHDL files, is simulated by Xilinx 
> Vivado 2015.3 at a speed of 400 clock cycles per second.
> 
> For all other designs I have and/or generate, GHDL is always noticeably 
> faster that Vivado, so I think my current app exhibits a GHDL behaviour that 
> at least could be improved.
> 
> Note that the attached VHDL was generated by a HLS tool so it's not easy to 
> read... and unfortunately I can't reduce the VHDL code to something simpler 
> that exhibits the slowdown.
> 
> The top-level entity is the testbench entity "tb". The simulation is supposed 
> to stop after around 550k clock cycles.
> 
> Good evening,
> Adrien
> ___
> Ghdl-discuss mailing list
> Ghdl-discuss@gna.org
> https://mail.gna.org/listinfo/ghdl-discuss


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] git e7adf19

[David Koontz]

> On 24/02/2016, at 6:36 am, Thomas Sailer  wrote:
> 
> Hi Tristan / List,
> 
> I'm having a few issues with e7adf19.
> 
> When compiling a design with mcode, I get:
> 
> error_emit: emit_insn: move/b2, insn= 184 (OE_MOVE)
> 
> Message: ortho_code-x86-emits.adb:146 explicit raise

This looks like a missing error handler for the mcode version.

> With gcc or llvm, I can compile the design, but when trying to run, I get:
> 
> ./xx
> (unknown signal)
> ./xx:error: several sources for unresolved signal
> ./xx:error: error during elaboration
> for signal:

This last is a run time message during execution of xx. It's telling you there 
are multiple drivers for a signal of an unresolved type:

entity foo is
end entity;

architecture fum of foo is
signal a: bit;
begin
a <= '0';
a <= '1';
end architecture;


> How can I get further information which signal is causing this? The design 
> works in another commercial simulator, not that that means a lot standards 
> compliance wise...

This commercial simulator may not be standard compliant:

IEEE Std 1076-2008 6.4.2.3 Signal declarations paragraph 7:

A signal may have one or more sources. For a signal of a scalar type, each 
source is either a driver (see 14.7.2) or an out, inout, buffer, or linkage 
port of a component instance or of a block statement with which the signal is 
associated. For a signal of a composite type, each composite source is a 
collection of scalar sources, one for each scalar subelement of the signal. It 
is an error if, after the elaboration of a description, a signal has multiple 
sources and it is not a resolved signal. It is also an error if, after the 
elaboration of a description, a resolved signal has more sources than the 
number of elements in the index range of the type of the formal parameter of 
the resolution function associated with the resolved signal.

(Emphasis added. Alternatively see paragraph 9 of IEEE Std 1076-1993 4.3.1.2 
Signal declarations, it's identical except the sub clause reference).

With the llvm version there is no further information forthcoming:

 ghdl -r foo
a
./foo:error: several sources for unresolved signal
./foo:error: error during elaboration
for signal: .foo(fum).

(And a missing trailing newline as well as a missing signal name).

If you were to postulate the same cause for mcode and llvm versions there's 
something missing to output the signal name to standard_out.

In grt/grt-signals.adb:333:359:

procedure Check_New_Source (Sig : Ghdl_Signal_Ptr)
   is
  use Grt.Stdio;
  use Grt.Astdio;
   begin
  if Sig.S.Nbr_Drivers + Sig.Nbr_Ports > 0 then
 if Sig.S.Resolv = null then
--  LRM 4.3.1.2 Signal Declaration
--  It is an error if, after the elaboration of a description, a
--  signal has multiple sources and it is not a resolved signal.
if Sig.Rti /= null then
   Put ("for signal: ");
   Disp_Signals.Put_Signal_Name (stderr, Sig);
   New_Line (stderr);
end if;
Error ("several sources for unresolved signal");
 elsif Sig.S.Mode_Sig = Mode_Buffer and False then
--  LRM 1.1.1.2  Ports
--  A BUFFER port may have at most one source.

--  FIXME: this is not true with VHDL-02.
--  With VHDL-87/93, should also check that: any actual associated
--  with a formal buffer port may have at most one source.
Error ("buffer port which more than one source");
 end if;
  end if;
   end Check_New_Source;

It looks like a problem with the Disp_Signals.Put_Signal_Name call.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] SYSTEM.ASSERTIONS.ASSERT_FAILURE in trans.adb:393 (Set_Scope_Via_Param_Ptr)

[David Koontz]

> On 2/12/2015, at 9:45 am, Attila Kinali  wrote:
> 
> http://attila.kinali.ch/tdc/

david_koontz@Macbook: ghdl -a --std=08 tdc_lbc_cls.vhd

 GHDL Bug occured 
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.33 (20150921) [Dunoon edition]
Compiled with GNAT Version: GPL 2015 (20150428-49)
In directory: /Users/david_koontz/Desktop/atilla kinali/tdc/
Command line:
/usr/local/bin/ghdl1-llvm --std=08 -P/usr/local/lib/ghdl/v08/std/ 
-P/usr/local/lib/ghdl/v08/ieee/ -c -o tdc_lbc_cls.o tdc_lbc_cls.vhd
Exception SYSTEM.ASSERTIONS.ASSERT_FAILURE raised
Exception information:
Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: trans.adb:393
Load address: 0x101556000
Call stack traceback locations:
0x102018791 0x101673440 0x101694338 0x1016909cf 0x1016912d0 0x101690f3e 
0x1016913a5 0x1016dcecc 0x10167e1d6 0x1016e2158 0x101596c0e 0x101557cda
**
ghdl: compilation error

 —

entity tdc_lbc_cls is

and down in the second generate statement:

CLS: entity tdc_lbc_cls
generic map (
g_N => g_N-1,
g_NIN => g_NIN/2
)


If you take out the reserved word entity:

david_koontz@Macbook: ghdl -a --std=08 tdc_lbc_cls.vhd
tdc_lbc_cls.vhd:107:21: component name expected, found entity "tdc_lbc_cls"
ghdl: compilation error

And if you add a component declaration:

architecture rtl of tdc_lbc_cls is

component tdc_lbc_cls is
generic (
-- Number of output bits.
g_N: positive;
  -- Number of input bits. Maximum is 2^g_N-1.
g_NIN: positive
);
port (
clk_i:  in  std_logic;
reset_i:in  std_logic;
symbol_i:   in  std_logic;
d_i:in  std_logic_vector(g_NIN-1 downto 0);
count_o:out std_logic_vector(g_N-1 downto 0)
);
end component;
begin

david_koontz@Macbook: !!
ghdl -a --std=08 tdc_lbc_cls.vhd
david_koontz@Macbook:

It analyzes (and the entire thing elaborates)

Note the failing direct entity instantiation entity name is not an expanded 
name.  Making it one doesn't fix the uncaught error (giving the same line 
number in trans.adb).

Anyway, there's an uncaught error and a workaround (use component instantiation 
instead of direct entity instantiation).



david_koontz@Macbook: tb_lbc
tb_lbc.vhd:157:17:@10ns:(report note): Vector out: 
101010011011001011101110010011101101001001110010101 (polarity: 1)
tb_lbc.vhd:157:17:@20ns:(report note): Vector out: 
00111010100000110010011010110100101001011001100 (polarity: 0)
tb_lbc.vhd:157:17:@30ns:(report note): Vector out: 
1110011010100101001011000111011011110010101 (polarity: 1)
tb_lbc.vhd:169:17:@30ns:(report note): Result in: expected:1(1) output:1(1)
tb_lbc.vhd:157:17:@40ns:(report note): Vector out: 
111010001000111010010011101010101100100 (polarity: 0)
tb_lbc.vhd:169:17:@40ns:(report note): Result in: expected:2(0) output:2(0)
tb_lbc.vhd:157:17:@50ns:(report note): Vector out: 
101010000010101101011000100101110100101010110001110 (polarity: 1)
tb_lbc.vhd:169:17:@50ns:(report note): Result in: expected:3(1) output:3(1)
tb_lbc.vhd:157:17:@60ns:(report note): Vector out: 
001100010110101101010110101110100100010010001001101 (polarity: 0)
tb_lbc.vhd:169:17:@60ns:(report note): Result in: expected:4(0) output:4(0)
tb_lbc.vhd:157:17:@70ns:(report note): Vector out: 
1111001010101000100110110000110100101110111 (polarity: 1)
tb_lbc.vhd:169:17:@70ns:(report note): Result in: expected:5(1) output:5(1)
tb_lbc.vhd:157:17:@80ns:(report note): Vector out: 
1101010111101110010001100101110110011010010 (polarity: 0)
tb_lbc.vhd:169:17:@80ns:(report note): Result in: expected:6(0) output:6(0)
tb_lbc.vhd:157:17:@90ns:(report note): Vector out: 
1001010111100100110110011000110 (polarity: 1)
tb_lbc.vhd:169:17:@90ns:(report note): Result in: expected:7(1) output:7(1)
tb_lbc.vhd:157:17:@100ns:(report note): Vector out: 
001101001101001111011101100011101101100 (polarity: 0)
tb_lbc.vhd:169:17:@100ns:(report note): Result in: expected:8(0) output:8(0)
tb_lbc.vhd:157:17:@110ns:(report note): Vector out: 
111001100101100010001001101101100110111000110110000 (polarity: 1)
tb_lbc.vhd:169:17:@110ns:(report note): Result in: expected:9(1) output:9(1)
tb_lbc.vhd:157:17:@120ns:(report note): Vector out: 
110010011000010110010010011001110101011 (polarity: 0)
tb_lbc.vhd:169:17:@120ns:(report note): Result in: expected:10(0) output:10(0)
tb_lbc.vhd:157:17:@130ns:(report note): Vector out: 
10101001010011000110010101011011001100010001110 (polarity: 1)

Re: [Ghdl-discuss] Bug in array signal asignment

[David Koontz]

> On 27/11/2015, at 4:43 pm, Tristan Gingold  wrote:
> 
> I would simply add that this is one of vhdl pitfall.  VHDL behaviour
> is not very intuitive.
> 
> This could be detected at elaboration time by using std_ulogic instead of 
> std_logic.
> 
> (You'd better to always use std_ulogic and std_ulogic_vector. Unfortunately, 
> it was not possible to mix them without adding conversions and most of IP 
> blocks are using std_logic).

I'd claim the LRM could be re-written to make it clearer. Not likely to happen, 
verifying the standard would be a major undertaking at it's present thud factor 
(http://wordspy.com/index.php?word=thud-factor).

See IEEE-Std 1800-2012 11.5.3 Longest static prefix:

Informally, the longest static prefix of a select is the longest part of the 
select for which an analysis tool has known values following elaboration. This 
concept is used when describing implicit sensitivity lists (see 9.2.2.2) and 
when describing error conditions for drivers of logic ports (see 6.5). The 
remainder of this subclause defines what constitutes the “longest static 
prefix” of a select.

A field select is defined as a hierarchical name where the right-hand side of 
the last “.” hierarchy separator identifies a field of a variable whose type is 
a struct or union declaration. The field select prefix is defined to be the 
left-hand side of the final “.” hierarchy separator in a field select.

An indexing select is a single indexing operation. The indexing select prefix 
is either an identifier or, in the case of a multidimensional select, another 
indexing select. Array selects, bit-selects, part-selects, and indexed 
part-selects are examples of indexing selects.

The definition of a static prefix is recursive and is defined as follows:

—  An identifier is a static prefix.

—  A hierarchical reference to an object is a static prefix.

—  A package reference to net or variable is a static prefix.

—  A field select is a static prefix if the field select prefix is a 
static prefix.

—  An indexing select is a static prefix if the indexing select prefix 
is a static 
   prefix and the select expression is a constant expression.

The definition of the longest static prefix is defined as follows:

—  An identifier that is not the field select prefix or indexing select 
prefix of an 
   expression that is a static prefix.

—  A field select that is not the field select prefix or indexing 
select prefix of an 
   expression that is a static prefix.

—  An indexing select that is not the field select prefix or indexing 
select prefix of 
   an expression that is a static prefix.

https://standards.ieee.org/getieee/1800/download/1800-2012.pdf

(It's not just a VHDL pitfall). 

A search of "longest static prefix"[vhdl] on Stackoverflow and StackExchange 
returned no hits, nor is the string "longest static prefix" common in VHDL 
books.

It's just not taught or presented so you can learn about it easily.

(And ya, there are parts of the System Verilog LRM that are hard to read. On 
the other hand what do you want to bet the list of things described more or  
less explicitly as locally or globally static won't grow in the VHDL LRM?)


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] integer range

[David Koontz]

> On 25/11/2015, at 9:10 am, René Doß  wrote:
> 
> 
> I have a question. What is the range of integer in GHDL?

type integer is range -2147483648 to 2147483647;

> This works   (wert>2^31):
>  signal wert: std_logic_vector(31 downto 0):= X"";
>  signal a: integer:= to_integer(unsigned(wert));
> 
> 
> This  produce an error (c=2^31):
>  signal c: integer:=2**31;

  2**31 = 2147483648 (according to Apples calculator app)

IEEE Std 1076-2008 5.2.3.2 Predefined integer types

The only predefined integer type is the type INTEGER. The range of INTEGER is 
implementation dependent, but it is guaranteed to include the range –2147483647 
to +2147483647. It is defined with an ascending range.

NOTE—The range of INTEGER in a particular implementation is determinable from 
the values of its 'LOW and 'HIGH attributes.

You should be using 2**31-1.

You could also note that the range in declaration of type INTEGER from the 
pseudo package STANDARD dumped out by --disp-standard) would not be legal as a 
new INTEGER type declaration.

type integer is range -2147483648 to 2147483647;

the left bound given as sign operator, decimal literal (basic operation to 
universal integer, implicit conversion to the widest range predefined integer 
type (INTEGER), whose right bound abstract literal (decimal literal) 2147483648 
is out of bounds for type INTEGER.

> hometown.vhd:34:23: static constant violates bounds
> ghdl: compilation error
> makefile:4: recipe for target 'all' failed
> 


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Include libraries in GHDL

[David Koontz]

> On 25/11/2015, at 5:33 am, João Malés  wrote:
> 
> I'm using GHDL to simulate some designs that I'm doing. Now, I included the 
> float_pkg package to work with floats in Sigasi but when I'm simulating in 
> GHDL it states that  "primary unit "float_pkg" not found in library "ieee" “.

float_package, float_generic_pkg, etc. are available as part of IEEE Std 
1076-2008 (http://standards.ieee.org/downloads/1076/1076-2008/, the zip file, 
when expanded subdirectory ieee). In general you’d have to back port them to an 
earlier revision. It could be onerous, they’d take advantage of changes to the 
standard. David Bishop used to make back ported versions available on eda.org 
for -1993, (eda.org sponsored by Mentor will be closed down shortly, See 
http://www.eda.org/fphdl/, VHDL-93 versions of the VHDL-2008 packages, try ZIP 
file of all the packages ).

> 
> How can I add this new library to GHDL? Copy/paste to the GHDL>lib where we 
> have two folders "v93" and "v87" doesn't seem to work.

There are both library sources and analyzed library entries. Simply dumping the 
sources in the IEEE library source doesn’t provide access. (And opens a can of 
compatibility worms).

> I'm using GHDL 0.25 on Windows.

If you were to download ghdl-0.33 for Windows 
(http://sourceforge.net/projects/ghdl-updates/files/Builds/ghdl-0.33/, the link 
to ghdl-0.33-win32.zip), you’d have the packages installed. There’s a command 
line flag for revision -2008 (--std=08, given after a command   (-a/-e for 
analysis/elaboration) of the standard you could pass to provide access.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Switching to git

[David Koontz]

> On 19/11/2015, at 7:56 am, Tristan Gingold  wrote:
> 
> https://github.com/tgingold/ghdl
> 
>> - removing the old hg repo.
> 
> Will remove the old hg repo later.

The releases (0.31 - 0.33) don’t show up as branches.

(I lament the loss of the Revision column in SourceTree, even if the number was 
approaching 1000).




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Switching to git

[David Koontz]

> On 19/11/2015, at 8:28 am, Tristan Gingold <tging...@free.fr> wrote:
> 
> On 18/11/15 20:09, David Koontz wrote:
>> 
>>> On 19/11/2015, at 7:56 am, Tristan Gingold <tging...@free.fr> wrote:
>>> 
>>> https://github.com/tgingold/ghdl
>>> 
>>>> - removing the old hg repo.
>>> 
>>> Will remove the old hg repo later.
>> 
>> The releases (0.31 - 0.33) don’t show up as branches.
> 
> Now fixed.

Cool.

> 
>> (I lament the loss of the Revision column in SourceTree, even if the number 
>> was approaching 1000).
> 
> Sorry, I cannot do anything for that :-(
> There is the number of commits however.

Ya, well if was generally useful the feature would be in there.




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Next release 0.33

[David Koontz]

Is this one of those ‘Doctor it hurts when I do that’ moments?

originally defined in grt_sigsegv_handler() found in linux.c:

  ucontext_t *uctxt = (ucontext_t *)ptr;

Note the comment on line 88 of jumps.c saying grt_sigsegv_hander() is only used 
by mcode.

Without more research I couldn’t tell you whether or not you need it in i386 on 
Linux (or whether or not an i386 llvm based ghdl makes any sense). I was 
curious about the missing declaration.



> On 1/10/2015, at 12:04 am, Joris van Rantwijk  wrote:
> 
> On 2015-09-29, Tristan Gingold wrote:
>> I'd like to build the release this week.  Can you confirm that
>> your favorite testbench/testsuite works with the tip ?
> 
> When building the LLVM backend on i386, I get compiler errors.
> 
> src/grt/config/jumps.c: In function ‘grt_sigsegv_handler’:
> src/grt/config/jumps.c:92:7: error: ‘uctxt’ undeclared (first use in this 
> function)
>   if (uctxt->uc_mcontext.gregs[REG_TRAPNO] == 4)
>   ^
> src/grt/config/jumps.c:92:7: note: each undeclared identifier is reported 
> only once for each function it appears in
> src/grt/config/jumps.c:92:32: error: ‘REG_TRAPNO’ undeclared (first use in 
> this function)
>   if (uctxt->uc_mcontext.gregs[REG_TRAPNO] == 4)
>^
> src/grt/Makefile.inc:110: recipe for target 'jumps.o' failed
> 
> --
> Joris.
> 
> ___
> Ghdl-discuss mailing list
> Ghdl-discuss@gna.org
> https://mail.gna.org/listinfo/ghdl-discuss


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] I want report a bug

[David Koontz]

OS X gives the same results:

david_koontz@Macbook: make
rm -rf work
mkdir work
ghdl -a  --work=work --workdir=work sim_pkg.vhd
gcc -c -fPIC sim.c -o sim.o
ghdl -a  --work=work --workdir=work tb_cosim.vhd

 GHDL Bug occured 
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.31 (20140108) [Dunoon edition]
Compiled with GNAT Version: GPL 2013 (20130314)
In directory: /Users/david_koontz/Desktop/reneedoss/
Command line:
/opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1 
--work=work --workdir=work 
-P/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/std/
 
-P/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/ieee/
 -quiet -o work/tb_cosim.s tb_cosim.vhd
Exception TYPES.INTERNAL_ERROR raised
Exception information:
Exception name: TYPES.INTERNAL_ERROR
Message: sem_names.adb:1847
Call stack traceback locations:
0x105b77a34 0x105b78a91 0x105b7f23c 0x105b831af 0x105b7f368 0x105b831af 
0x105b7f368 0x105b7e5a0 0x105b6b219 0x105b6b70f 0x105b90134 0x105b876c9 
0x105b6c279 0x105b91725 0x105b615d1 0x105b62737 0x105abb024 0x105a9b8b3 
0x105aa70ef 0x105aa8c1a 0x105a9e65e 0x105abb084 0x105a9ac04
**

Execution terminated by unhandled exception
Exception name: TYPES.INTERNAL_ERROR
Message: sem_names.adb:1847
Call stack traceback locations:
0x105b77a34 0x105b78a91 0x105b7f23c 0x105b831af 0x105b7f368 0x105b831af 
0x105b7f368 0x105b7e5a0 0x105b6b219 0x105b6b70f 0x105b90134 0x105b876c9 
0x105b6c279 0x105b91725 0x105b615d1 0x105b62737 0x105abb024 0x105a9b8b3 
0x105aa70ef 0x105aa8c1a 0x105a9e65e 0x105abb084 0x105a9ac04
ghdl: compilation error
make: *** [all] Error 1

Shotgunning by commenting out the processes then the function declaration/body 
in tb_cosim.vhd show it’s the crc function causing the problem. (ghdl -a 
tb_cosim.vhd)

Undoing commenting out as a troubleshooting method leaves this as the offending 
line in function crc:

  crc_out := (crc(3 downto 0)  crc_out(31 downto 4)) xor crc;

Note that crc_out isn’t initialized and is guaranteed to propagate ‘U’s for 
part of it’s range of elements, and giving a default value: 

variable crc_out : std_logic_vector(31 downto 0) := (others = '1');

makes no difference.

And on closer examination we find that crc is called recursively twice:

  crc_out := (crc(3 downto 0)  crc_out(31 downto 4)) xor crc;
  ^---^

That should be crc_value. Note there is no argument and no default value.

The line should look something like:

   crc_out := (crc_value(3 downto 0) crc_out(31 downto 4)) xor crc_value;

After which tb_cosim.vhd analyzes.

So the problem occurs when you trip across is the first invocation - crc(3 
downto 0) during analysis.

The occurrence of the name crc appears legal within the scope of the function 
specification.

There’s a missing association list for the call to crc (crc_value doesn’t have 
a default value) that’s not being detected when taking a slice of the result, 
regardless that isn’t what’s intended. You could also note recursive invocation 
of crc doesn’t look like it does or could do anything meaningful.

You could notice that if you only fix the first crc reference:

 crc_out := (crc_value(3 downto 0) crc_out(31 downto 4)) xor crc;

You get:

david_koontz@Macbook: ghdl -a tb_cosim.vhd  
tb_cosim.vhd:32:67: function crc requires parameters
ghdl: compilation error

We’re missing the same check when using a slice of a function return value.


 On 28/08/2015, at 6:57 am, René Doß d...@gmx.de wrote:
 
 I want also report a bug.
 
 
  GHDL Bug occured 
 Please report this bug on http://gna.org/projects/ghdl
 GHDL release: GHDL 0.31 (20140108) [Dunoon edition]
 Compiled with GNAT Version: 4.8.3 20140627
 In directory: /home/red/ghdl/
 Command line:
 /opt/ghdl/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/ghdl1 --work=work
 --workdir=work
 -P/opt/ghdl/lib64/gcc/x86_64-unknown-linux-gnu/4.8.2/vhdl/lib//v93/std/
 -P/opt/ghdl/lib64/gcc/x86_64-unknown-linux-gnu/4.8.2/vhdl/lib//v93/ieee/
 -quiet -o work/tb_cosim.s tb_cosim.vhd
 Exception TYPES.INTERNAL_ERROR raised
 Exception information:
 Exception name: TYPES.INTERNAL_ERROR
 Message: sem_names.adb:1847
 Call stack traceback locations:
 0x61690f 0x617c72 0x61e5c7 0x61fb33 0x61e1b5 0x61fb33 0x61e1b5 0x61bdae
 0x60a909 0x60b12e 0x62d868 0x624bf5 0x60bc95 0x62f6d5 0x60121b 0x6022e5
 0x567ea5 0x54af93 0x555f44 0x557a28 0x54dac1 0x567ef9 0x549881
 0x7f2ef3932b03 0x549a53 0xfffe
 **
 
 Execution terminated by unhandled exception
 Exception name: TYPES.INTERNAL_ERROR
 Message: sem_names.adb:1847
 Call stack traceback locations:
 0x61690f 0x617c72 0x61e5c7 0x61fb33 0x61e1b5 0x61fb33 0x61e1b5 0x61bdae
 0x60a909 

Re: [Ghdl-discuss] Error while handling floating point literals in physical literals

[David Koontz]

On 9/06/2015, at 10:33 am, Lehmann, Patrick patrick.lehm...@tu-dresden.de 
wrote:

 Here are further tests:
 
 ghdl 0.31 on windows:
 C:\Tools\GHDL\0.31\bin\ghdl.exe: poc-obj93.cf: bad library format
 
 ghdl 0.32 on windows:
 C:\Tools\GHDL\0.32\bin\ghdl.exe: poc-obj93.cf: bad library format
 
 ghdl 0.33dev (hg commit 821) on windows:
 build_constant: cannot handle IIR_KIND_PHYSICAL_FP_LITERAL 
 (D:\git\SATAController\lib\PoC\tb\misc\misc_Noise_tb.vhdl:17:115)
 
 It's independent of '--std=93/02/08'.

Throw away the library and reanalyze it.

Didn't Tristan do something with how the dates were stored in it?  The format 
would have changed.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Error while handling floating point literals in physical literals

[David Koontz]

On 9/06/2015, at 8:15 am, Tristan Gingold tging...@free.fr wrote:

 On 08/06/15 21:55, Lehmann, Patrick wrote:
 Hello,
 
 I got an error message that says handling of floating point literals in
 physical literals is not supported.
 
 I can change my code, because it’s just a ‘100.0 MHz’ constant. Is this
 a features that will be implemented
 
 in the future? If I remember correctly, VHDL allows floating point
 literals in physical literal definitions.
 
 I cannot reproduce the error with the trunk version of ghdl, so I
 suppose the issue has already been fixed!

It analyzes with ghdl-0.31 on OS X (the gcc version and the mcode version).
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Error while handling floating point literals in physical literals

[David Koontz]

On 9/06/2015, at 11:10 am, Lehmann, Patrick patrick.lehm...@tu-dresden.de 
wrote:

 
 so ignore my tests on ghdl 0.31 and 0.32rc1 on windows.
 I cannot test it without many changes to my environment ...
 ghdl uses the analyzed libs from 0.33dev :(


You can test it without your library:

package physical is
  type FREQ is range 0 to INTEGER'high units
Hz;
kHz = 1000 Hz;
MHz = 1000 kHz;
GHz = 1000 MHz;
--THz = 1000 GHz;
  end units;
end package;
 
--library PoC;
--use PoC.physical.all;
use work.physical.all;

entity misc_Noise_tb is
end;
 
architecture test of misc_Noise_tb is
  constant CLOCK_FREQ: FREQ:= 100.0 MHz;
begin
  -- empty
end architecture;

I think any data points on where it goes bad on Windows are worthwhile.

You could 'hunt' further down the release tree assuming ghdl mcode is 
relatively painless to build on Windows.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Optimization of the generics at compile-time

[David Koontz]

On 8/05/2015, at 5:29 am, Tristan Gingold tging...@free.fr wrote:

 gcc already generates good code for ieee packages, but that's not enough.  We 
 could avoid recomputing bounds for these functions, as
 they could be deduced at compile-time for most cases.

This seems a bit unclear, subprogram calls are dynamically elaborated.




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] --time-resolution

[David Koontz]

On 7/04/2015, at 6:55 am, Paul Koning paulkon...@comcast.net wrote:

 
 On Apr 6, 2015, at 2:48 PM, Tristan Gingold tging...@free.fr wrote:
 
 On 05/04/15 18:03, Adam Jensen wrote:
 ...
 With the time-resolution fixed to femto seconds, the total simulation time 
 is limited to about 2.6 hours.
 
 2^63 * 1e-15 sec ~= 153.723 min
 
 If events in a model occur on the scale of minutes, the simulations are 
 very limited.
 
 Yes, but is there a real case for that ?  In microelectronics,
 propagation time is not in minutes!
 
 True, but elapsed time between external inputs might be.  Suppose you’re 
 modeling a data capture system, with a clock on the order of milliseconds, 
 and external events minutes or hours apart.  The propagation delays in that 
 case are essentially zero, but the behavior has time units matching the clock 
 period, and for a slow clock situation, femtoseconds are not really useful.

VHDL models are event driven not time driven, the notion of time is 
superimposed on the occurrence of events. 

You can model an alarm clock chip in VHDL and synthesize it.  Simulation (a 
computer model of) doesn't require you run the model for 24 hours (or 7 days, 
or ...), that would be emulation (- Computing reproduce the function or action 
of (a different computer, software system, etc.). Verification requires you 
produce observable events, and to do so you can manipulate the design model 
state.  Emulation requires you generate all the events.

I personally favor the idea of implementing an assignable resolution limit. If 
I ever finish and release my implementation it will have it.  However, it's of 
limited usefulness. Todays 'microelectronics' requires timing resolution finer 
than the nanosecond scale.

You're bound to trip over someone for whom a thousand times increase in time 
(using ps) isn't enough to emulate time driven simulation incorporating 
microelectronics much less Adam's other than microelectronics.

You could also note that from IEEE Std 1076-2008 5.2.4.2, the use of nested 
'may's and Annex D, Potentially nonportable constructs, you can't expect 
resolution-limit use to be portable. 

The question is whether or not the VHDL standard will ever embrace sufficient 
accuracy to relate to time driven modeling. It doesn't appear to be within the 
scope of the VHDL language. See the Introduction in the standard. And if it did 
embrace it, resolution limit would likely be required.

And as for Adam's other than microelectronics

He could always define a new physical type with it's own units and use some 
conversion routines to convert it back and forth to type TIME with a resolution 
limit scaling.  A 32 bit INTEGER ranged Physical Type would be portable and 
have the range for a years worth of milliseconds.  You could equate a 
millisecond to a femtosecond. 

You can deal with larger values of the new time type by first converting them 
to type Time and using multiplying operators, see 9.2.7 Multiplying operators, 
the second table.

There isn't a requirement that a report statement provide the simulation time, 
see 10.4 Report statement, para 5, a) through d).  This shows why always 
providing it can limiting.  A to_string or a 'IMAGE would provide a proper 
representation of your new physical type. See 9.7 String representations.

There could also have a routine for scaling to secondary units as a string 
instead of 'IMAGE and so on.

You'd use a conversion routine to Time where you'd want to provide an 
expression of type Time for a delay, etc. There are places where a Time 
expression is required to be static which would require a constant declaration 
for type Time, which can have an initial value from a conversion routine.

Admiral, if we go by the book, like Lieutenant Saavik, hours could seem like 
days. 

Substituting femtoseconds for hours and milliseconds for days. It does the same 
thing as a settable resolution limit albeit with a slight crudity with savings 
grace of being portable
(unless someone were to rely on some other nonportable feature as well).




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Instantiate component with floating pin

[David Koontz]

On 13/01/2015, at 9:37 am, Tristan Gingold tging...@free.fr wrote:

 Indeed, GHDL is correct.  See LRM93 4.3.2.2 Association lists:
 
 Furthermore, every scalar subelement of the explicitly declared interface 
 object must be associated exactly once with an actual (or subelement thereof) 
 in the same association list, and all such associations must appear in a 
 contiguous sequence within that association list.
 
 So, the only way for GHDL to compile it is first to fix it, using eg a
 dummy signal.

And right before the NOTES in 4.3.2.2:

It is an error if an actual of open is associated with a formal that is 
associated individually. An actual of open counts as the single association 
allowed for the corresponding formal but does not supply a constant, signal, or 
variable (as is appropriate to the object class of the formal) to the formal.

  --

So you can't use an open association with the remaining subelement of the 
formal. And that paragraph is also found in -2008, 6.5.7.1 so you can't point 
to differences in the standard in support of different behavior by various 
tools.

And there are two ways to supply a dummy, expanding the actual to contain more 
elements than are used or use a separate dummy signal that is associated with 
the individual formal subelement:

oData(8) = dummy(i),
oData(7 downto 0) = HRDATA(8 * i + 7 downto 8 * i),

And that is acceptable to ghdl, while not requiring selection when the data is 
actually used.







___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] IEEE library license (was: Re: Release 0.32 - debian package)

[David Koontz]

On 5 Nov 2014, at 2:55 pm, why...@f-cpu.org wrote:

 These limitations are no practical problem for ghdl itself, just for
 inclusion in Debian with its high standard of software freeness. That is
 if the copyright on the spec files is actually relevant.
 
 That's my opinion too.

I'll reserved judgement for the outcome of Oracle v. Google before the Supreme 
Court over APIs.




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] An Eclipse IDE for GHDL with GTKWAVE integrated

[David Koontz]

On 22 Jul 2014, at 9:32 pm, Nicole Fontenot robwob...@gmail.com wrote:

 Give me some time to look over the Exuberant Ctags code-base and I'll see 
 what I can do.
 Can there be some general discussion with, exactly what are the shortcomings 
 of the current parser:
 Is there a problem with ctags not understanding that entity blocks and 
 architecture blocks are connected in a fundamental way?
 Are there library functions and constructs that are just too much for the 
 current implementation? What do those look like?
 Is ctags recognition outdated?
 Is it ctags job to recognize things like flipflops, muxers or 
 non-synthesizable  constructs?
 I know the topic was on a project of larger scope but, for an IDE ctags is an 
 important part of what people expect from one.
 Without good parsing support, the market for the up-and-coming IDE will be 
 blasé at best. With this and that I work a full time job in mind, 
 don't expect sudden results; If there is a wanting for new features I will do 
 my best.
 



I think it would be useful to be able to reference every named object 
explicitly or implicitly declared:

(This from VHDL93)
 entity_class ::=   [§ 5.1]
entity  | architecture   | configuration
 | procedure| function   | package
 | type | subtype| constant
 | signal   | variable   | component
 | label| literal| units
 | group| file
(VHDL 2008 adds property and sequence both found in PSL).  Notice alias is 
missing.
Something like the implicitly declared parameters from a for generation scheme 
or loop statement iteration scheme would be clearly out of reach of a 
non-thorough parser.  I'd suspect labels are too, being context sensitive used 
in object declaration as well (constants, signals, variables and files).

There's issue both with ctags and any editor understanding scope, visibility 
and declarative regions (which would give you the generation or iteration 
scheme variables). Even an architecture name exists in a separate declarative 
region for component instantiation.  Primary units declarative regions can 
extend to their secondary units (or a configuration specification).

Note there are places where object class defining reserved words (e.g. signal, 
variable) are optional (interface lists for entities and functions ).

Functions and procedures should be distinct, the former an expression the 
latter a statement.

And how do you distinguish between something in a package declaration and 
package body when they can be in two different design files? (e.g. 
std_logic_1164.vhdl std_logic_1164_body.vhdl).  It looks like name by name file 
and line number attributes.

I don't know about you but I'd love to have an editor that can filter by entity 
class for those times you know what something is but don't remember the exact 
name.  It's faster (for some of us) then coming up with a meta match value to 
search with.  The existing VHDL tags implementations tend to pour things into 
two few a number of cups, IIRC.

GTKWave has a new dump file format FST, which I've seen in one VHDL 
implementation (nvc) and has the ability to point at declarations from the  
signals pane, and allows opening an external editor on the declared line in the 
declared file.  nvc currently only points to declarative regions and by 
definition this only covers signals.  What's of interest is where the 
information comes from - nvc creates a structure containing all the  signals 
being queued for waveform dump  and looks up the location declarations, it's 
essentially done from the 'distributed' symbol table the same way you'd 
traverse and elaborated model looking for things to 'tag'.

This also points out you need an elaborated model to get an accurate set of 
tags or the ability to superimpose configuration on your results.  There's two 
few a number of cups in object files too, to distinguish even object classes 
(without a naming convention which would be implementation limited and likely 
platform limited).

And the moral here is not meant as discouragement but to encourage working 
toward a known goal.  Understand how big the problem is. Try for improvement 
over the 'state of the art'.

The last ctags source I have is 5.8 which shows a 29 June 2009 dated for 
vhdl.c. It supports limited VhdlKinds:

static kindOption VhdlKinds[] = {
{TRUE, 'c', constant, constant declarations},
{TRUE, 't', type, type definitions},
{TRUE, 'T', subtype, subtype definitions},
{TRUE, 'r', record, record names},
{TRUE, 'e', entity, entity declarations},
{FALSE, 'C', component, component declarations},
{FALSE, 'd', prototype, prototypes},
{TRUE, 'f', function, function prototypes and declarations},
{TRUE, 'p', procedure, procedure prototypes and declarations},
{TRUE, 'P', package, package definitions},

Re: [Ghdl-discuss] Release 0.31

[David Koontz]

On 8 Jan 2014, at 9:34 pm, tging...@free.fr wrote:

 
 It wouldn't hurt to have a wiki page on how to do -2008 features in
 ghdl.
 
 Something like:
 
 http://sourceforge.net/p/ghdl-updates/wiki/RoadMap2008/


No something that actually tells how to get the 2008 libraries into a useable 
state.  They are currently not delivered as part of make install.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Release 0.31

[David Koontz]

On 8 Jan 2014, at 12:33 pm, Brian Drummond br...@shapes.demon.co.uk wrote:

 At last I think I have it... 
 
 There are now two branches; ghdl-0.31 and default.
 
 After cloning the repo (hg clone) or pulling changes to an existing one,
 hg update ghdl-0.31
 will select the stable 0.31 branch, which can be built or packaged for
 release.
 
 hg update default
 should select the most current version; future changes should normally
 be to default unless they are critical and must be backported to
 0.31. 
 
 See
 http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html
 for some information on working with branches.
 
 I backported the copyright dates, as an exercise.  Then I made a commit
 to the default branch to keep tip attached to default, reducing the
 chance that a commit will happen to 0.31 by mistake...
 
 Hope it looks OK as an 0.31 release...
 I'll make a source download package tomorrow if I can.
 
 - Brian

more ../../version.ads
package Version is
   Ghdl_Release : constant String :=
  GHDL 0.31dev (20132311) [Dunoon edition];
   Ghdl_Ver : constant String := 0.31dev;
end Version;

[Shouldn't this be GHDL0.31 and have a date in January 2014?   You're Release 
0.31 doesn't appear quite finished yet.]



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Release 0.31

[David Koontz]

On 8 Jan 2014, at 1:03 pm, David Koontz diogra...@gmail.com wrote:

 
 On 8 Jan 2014, at 12:33 pm, Brian Drummond br...@shapes.demon.co.uk wrote:
 
 At last I think I have it... 
 
 There are now two branches; ghdl-0.31 and default.
 
 After cloning the repo (hg clone) or pulling changes to an existing one,
 hg update ghdl-0.31
 will select the stable 0.31 branch, which can be built or packaged for
 release.
 
 hg update default
 should select the most current version; future changes should normally
 be to default unless they are critical and must be backported to
 0.31. 
 
 See
 http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html
 for some information on working with branches.
 
 I backported the copyright dates, as an exercise.  Then I made a commit
 to the default branch to keep tip attached to default, reducing the
 chance that a commit will happen to 0.31 by mistake...
 
 Hope it looks OK as an 0.31 release...
 I'll make a source download package tomorrow if I can.
 
 - Brian
 
 more ../../version.ads
 package Version is
   Ghdl_Release : constant String :=
  GHDL 0.31dev (20132311) [Dunoon edition];
   Ghdl_Ver : constant String := 0.31dev;
 end Version;
 
 [Shouldn't this be GHDL0.31 and have a date in January 2014?   You're Release 
 0.31 doesn't appear quite finished yet.]

I patched version.ads so I could build.

We ought to contemplate modifying translate/gcc/Makefile.in to include 
installing the source for the ieee2008 vhdl libraries in the PREFIX target vhdl 
libraries src directory.  They are in the source distribution.

It wouldn't hurt to have a wiki page on how to do -2008 features in ghdl.

The build went swimmingly.

david_koontz@Macbook: ghdl --dispconfig
compiler command: 
/opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1
assembler command: as
linker command: gcc
command line prefix (--PREFIX): (not set)
environment prefix (GHDL_PREFIX): (not set)
default prefix: 
/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib/
actual prefix: 
/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib/
library directory: 
/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib/
compiler path: 
/opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1
assembler path: /usr/bin/as
linker path: /usr/bin/gcc
default library pathes:
 /opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/std/
 /opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/ieee/

david_koontz@Macbook: ghdl --version
GHDL 0.31 (20140801) [Dunoon edition]
 Compiled with GNAT Version: GPL 2013 (20130314)
 GCC back-end code generator
Written by Tristan Gingold.

Copyright (C) 2003 - 2014 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

After a bit of surety testing and waiting (antipodes) to see what your release 
image looks like, I'm ready to archive the OS X gcc version.

The entire OS X build is just shy of 80 MB installed.  Around 21 MB archived.





___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Release 0.31

[David Koontz]

On 7 Jan 2014, at 11:13 am, Brian Drummond br...@shapes.demon.co.uk wrote:

 I have also added the tag 0.31rc1 (Tristan, should I just re-tag as
 0.31?)

As soon as you do I'll build an OS X version.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL on FreeBSD with gcc-aux

[David Koontz]

On 3 Jan 2014, at 1:37 pm, Adam Jensen han...@riseup.net wrote:

 So far, my various attempts to build GHDL generally results in errors like:
 
 gmake[2]: *** No rule to make target `../gcc/gtype-vhdl.h', needed by 
 `ortho-lang.o'.  Stop.
 
 or:
 
 gcc   -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
 -Wstrict-prototypes -Wmissin
 g-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long 
 -Wno-variadic-macros -Wno-overlength-st
 rings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE  
 -o build/gengtype \
build/gengtype.o build/errors.o build/gengtype-lex.o 
 build/gengtype-parse.o build/gengtype-state.o b
 uild/version.o ../../build-i386-unknown-freebsd9.2/libiberty/libiberty.a
 /bin/sh ../.././gcc/../move-if-change tmp-gi.list gtyp-input.list
 echo timestamp  s-gtyp-input
 build/gengtype  \
-S ../.././gcc -I gtyp-input.list -w tmp-gtype.state
 ../.././gcc/vhdl/ortho-lang.c:1266: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1266: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1267: unidentified type `vec'
 ../.././gcc/vhdl/ortho-lang.c:1267: parse error: expected '(', 'GTY', or an 
 identifier, have ''
 ../.././gcc/vhdl/ortho-lang.c:1297: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1297: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1298: unidentified type `vec'
 ../.././gcc/vhdl/ortho-lang.c:1298: parse error: expected '(', 'GTY', or an 
 identifier, have ''
 ../.././gcc/vhdl/ortho-lang.c:1883: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1883: unexpected character `/'
 ../.././gcc/vhdl/ortho-lang.c:1884: unidentified type `vec'
 ../.././gcc/vhdl/ortho-lang.c:1884: parse error: expected '(', 'GTY', or an 
 identifier, have ''
 gmake[2]: *** [s-gtype] Error 1
 
 A quick web search indicates that this is a common problem but I haven't 
 found a solution or an explanation of what leads to this common class of 
 compilation error.
 
 A version of this Wiki page describing the build process with the
 dragonlace compiler would be a useful addition, so please keep us
 updated as to how you get on...
 
 
 Yes, definitely! Generously concise documentation written in such a way as to 
 actually be helpful is a nice addition to pretty much anything.

So far, my various attempts to build GHDL generally results in errors like:

Concise error reporting might help, too.

The above in ortho-lang.c looks like a compiler compatibility issue although 
I'd have thought they should have been one line earlier.  Line 1265 for 
instance has a c++ type comment with two slashes.

inline: Screen Shot 2014-01-03 at 4.13.17 pm.JPG

inline: Screen Shot 2014-01-03 at 4.17.57 pm.JPG


inline: Screen Shot 2014-01-03 at 4.19.13 pm.JPG

It looks like your compiler is not compatible through configuration or 
otherwise with those comment types (A C99 feature).

Note these line numbers don't match the latest version, Tristan is being 
prolific.  I'd suggest sticking to the ghdl-0.31 archive image which should be 
built against gcc-4.8.X (where X is currently 2).


The missing gtype-vhdl.h might be a dist.sh sources failure or perhaps using 
the wrong dist.sh script.  It should be in the top level of the vhdl directory 
to be installed under gcc-4.X.X/gcc .

It might also be the result of trying to build outside the parameters described 
in Brian's script/method.  The identical methodology is used to build under OS 
X 10.9.















___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] ghdl-updates / Wiki / build mcode ghdl

[David Koontz]

On 28 Dec 2013, at 11:03 am, Brian Drummond br...@shapes.demon.co.uk wrote:

 Thanks for the corrections - the important thing is, Torsten has a
 result.
 
 - Brian


I thought about calling you Brain again, but bit my tongue.

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] ghdl-updates / Wiki / build mcode ghdl

[David Koontz]

On 28 Dec 2013, at 10:07 am, Torsten Meißner tors...@meissneronline.net wrote:

 Yeah, installing the ada-4.4 version from the corrected link fixed my 
 problems.
 Thanks for your help, i really appreciate :)

As soon as I saw that darwin8 I knew it was my fault.  It didn't help someone 
built that version with all the style warnings turned on.  As near as I figure 
it's to allow someone's tool to do formal proof analysis, which says it isn't 
using a real Ada lexer more than likely (translation, it's old).

I spent the morning trying to trick the gnat gpl 2013 (x86_64) version into 
building a 32 bit ghdl executable.  Sort of like a handkerchief in a magician's 
fist, poke something in, something pops out elsewhere.  Looks like it might be 
worth building a 32 bit set of tools (a cross compiler sharing a TARGET but not 
ARCH).  I'm trying to do VHDL, not Ada.

The idea here is to do all this with the least amount of pain, sorry you fell 
in front of the lawn mower.  You did stay remarkably focused.   

I think you'd have and easier time build the gcc version of ghdl.  You'd likely 
be pleased with result (other than those pesky .o files).  Should be 20 percent 
or more faster.  It doesn't use these old tools to build either. The installed 
image is under 74 MB (a bit bigger than the ghdl mcode's 2.1 MB, but still in 
the noise even for an Air of late 2012 rMBP).  Tony's GTKWave.app is around 32 
MB.  I use the TextMate 2 beta (currently around 13.6 MB) a bit of a pain in 
the ass to do themes still, but supports Ada and VHDL grammar highlighting and 
text folding, spelling checking, various languages, file browser, you can show 
line numbers.  I think I'm using the starlight theme, there's no way to tell 
nondestructively, just big ol' UID, and nothing showing which one by name.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Building GHDL-mcode on OSX 10.9 fails

[David Koontz]

On 26 Dec 2013, at 10:42 pm, tging...@free.fr wrote:

 I think this version of gnat is slightly too old, that's the
 reason why you need to link with -no_compact_unwind.

Adacore unfortunately doesn't make a newer i386 gnat available any longer.

You should be able to re-link with the -no_compact_unwind flag.  It's the last 
step before make install.mcode, which likely should be redone, too.

rm ghdl_mcode
make target=darwin-i686

will demonstrate the the incorrect linking:

gnatlink ghdl_mcode.ali -g memsegs_c.o chkstk.o i386.o linux.o times.o 
grt-cbinding.o grt-cvpi.o

Where adding in the flag:

gnatlink -no_compact_unwind ghdl_mcode.ali -g memsegs_c.o chkstk.o i386.o 
linux.o times.o grt-cbinding.o grt-cvpi.o

david_koontz@Macbook: gnatlink --no_compact_unwind ghdl_mcode.ali -g 
memsegs_c.o chkstk.o i386.o linux.o times.o grt-cbinding.o grt-cvpi.o
ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: 
non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume: non-standard 
register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_RaiseException: 
non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: 
non-standard register 0 being saved in prolog

Doesn't appear to do anything different.

The ld command in question would be /usr/bin/ld dated 26 October, saying part 
of 10.9 install.





___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Building GHDL-mcode on OSX 10.9 fails

[David Koontz]

On 27 Dec 2013, at 1:36 am, tging...@free.fr wrote:

 
 gnatlink -no_compact_unwind ghdl_mcode.ali -g memsegs_c.o chkstk.o
 i386.o linux.o times.o grt-cbinding.o grt-cvpi.o
 
 No, you should write -Wl,-no_compact_unwind.

Oh I get it, pass the flag to the loader.

david_koontz@Macbook: gnatlink -Wl,-no_compact_unwind ghdl_mcode.ali -g 
memsegs_c.o chkstk.o i386.o linux.o times.o grt-cbinding.o grt-cvpi.o

Which works just fine without the warnings.

(Thanks)

Seeing as how gnatlink isn't called directly, can the flag be passed elsewhere, 
or is the easiest thing to do is at a relink target to the Makefile?  Some of 
us don't understand gnat.

GNAT_LARGS is supposed to be linker switches from a little googling.

Changed translate/ghdldrv/Makefile by adding line 40:

GNAT_LARGS= -Wl,-no_compact_unwind

(line 39 is commented out)

and:

david_koontz@Macbook: rm ghdl_mcode
remove ghdl_mcode? y
david_koontz@Macbook: make target=darwin-i686
curdir=`cd ..; pwd`; \
sed -e s%@COMPILER_GCC@%$curdir/ghdl1-gcc% \
 -e s%@COMPILER_DEBUG@%$curdir/ghdl1-debug% \
 -e s%@COMPILER_MCODE@%$curdir/ghdl1-mcode% \
 -e s%@COMPILER_LLVM@%$curdir/ghdl1-llvm% \
 -e s%@POST_PROCESSOR@%$curdir/../ortho/oread/oread-gcc% \
 -e s%@PREFIX@%$curdir/lib/%  default_pathes.ads.in  
default_pathes.ads
gnatmake -aI../../ortho/mcode -aI../../ortho -gnaty3befhkmr -gnata -gnatwae 
-aI../.. -aI.. -aI../../psl -aI../grt -aO.. -g -gnatf -gnat05 ghdl_mcode -bargs 
-E -largs memsegs_c.o chkstk.o -Wl,-no_compact_unwind i386.o linux.o times.o 
grt-cbinding.o grt-cvpi.o
gcc -c -I../../ortho/mcode -I../../ortho -gnaty3befhkmr -gnata -gnatwae -I../.. 
-I.. -I../../psl -I../grt -g -gnatf -gnat05 ghdllocal.adb
gcc -c -I../../ortho/mcode -I../../ortho -gnaty3befhkmr -gnata -gnatwae -I../.. 
-I.. -I../../psl -I../grt -g -gnatf -gnat05 default_pathes.ads
gcc -c -I../../ortho/mcode -I../../ortho -gnaty3befhkmr -gnata -gnatwae -I../.. 
-I.. -I../../psl -I../grt -g -gnatf -gnat05 ghdlcomp.adb
gnatbind -aI../../ortho/mcode -aI../../ortho -aI../.. -aI.. -aI../../psl 
-aI../grt -aO.. -E -x ghdl_mcode.ali
gnatlink ghdl_mcode.ali -g memsegs_c.o chkstk.o -Wl,-no_compact_unwind i386.o 
linux.o times.o grt-cbinding.o grt-cvpi.o
david_koontz@Macbook:

It worked.

(Sometimes it's convenient Tristan does this stuff for a living.)

And what's worse is I couldn't find -no_compact_unwind documented for Apple's 
ld.







___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Building GHDL-mcode on OSX 10.9 fails

[David Koontz]

On 27 Dec 2013, at 2:46 am, Torsten Meißner tors...@meissneronline.net wrote:

 
 default_pathes.ads:29:80: (style) this line is too long
 gnatmake: default_pathes.ads compilation error
 make: *** [ghdl_mcode] Error 4
 
 Maybe this can be workaround by building ghdl in a shorter directory path, 
 will try this next.
 

I know the gcc version of ghdl will bomb out if you have a space in the path to 
a tool.  I changed my login name to suit.

The warning as error bit is including style warnings which includes an 80 
column limit and no trailing spaces before and end of line.  Tristan has gotten 
all the latter out of the source code I think.  The line length is dependent on 
where you build from.  



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

[Ghdl-discuss] ghdl-updates / Wiki / build mcode ghdl

[David Koontz]

https://sourceforge.net/p/ghdl-updates/wiki/build%20mcode%20ghdl/

I added a caution about line lengths for default_pathes.ads in the second 
paragraph, and in the make command to build ghdl_mcode for OS X, added the 
linker switch:

# Mac OS X
# /usr/bin/make target=i686-darwin GNAT_LARGS=-Wl,-no_compact_unwind

(the default state for the script is to build on Linux)

I'm not sure why Torsten Meißner had all the difficulty.  He said he uses 
Homebrew which builds things in /usr/local.  

 ../../ortho/mcode/ortho_code-decls.ads:25:21: (style) bad column
 ../../ortho/mcode/ortho_code-decls.ads:28:21: (style) bad column
 ../../ortho/mcode/ortho_code-decls.ads:31:21: (style) bad column
 gnatmake: /Users/torsten/ghdl/ortho/mcode/ortho_code-decls.adb 

These sound like leading tab and space issues with comments (these are all 
comments, gnat is saying it doesn't like them indented extraordinarily).  I 
don't get them which says the particular style flag is turned off for me.  I 
never change gnat flags if I can help it, and I haven't.

There has to be something different about your gnat installation compared to 
mine.  Check you're environment for gnat things.  The other thing that comes to 
mind is changes to the Makefile which I also avoid.  (hence the make argument 
for GNAT_LARGS above).

In any event Tristan's suggestion of -gnatwa instead of -gnatwae should prevent 
gnat from being anal retentive.

I looked inside the disk image for the ada and didn't see anything.  You aren't 
trying to build this under Xcode, are you?











___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] First play with the testsuite...

[David Koontz]

On 27 Dec 2013, at 4:41 pm, tging...@free.fr wrote:

 Argh, I think that's now done: the vests test suite is clean for me.
 Do not hesitate to second check.


So how about a wiki page with the results?


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] configure for GHDL OS X

[David Koontz]

On 25 Dec 2013, at 2:09 am, René Doß d...@gmx.de wrote:

 This could likewise go into a makefile with the exception that wget isn't 
 native to OS X.
 
 wget is also available for MAC OS.
 I think it is simplier to install wget as to find out what is wrong in the 
 deep of gcc. This makefile can be a validation standard for compiling on 
 different systems. The make file save time.

Building wget from source is a bit too complicated to drop in the middle of 
building ghdl.  It doesn't account for someone already having wget, implying 
the whole thing needs an umbrella (automake, configure, ...), likely also 
implied for different target platforms for things like executable suffixes.

It might be simpler to replace the download_prerequisites script with something 
curl-ish.

Feel free to bell the cat.






___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Seeking comments on my cloud based verification ide

[David Koontz]

On 23 Dec 2013, at 8:40 pm, tging...@free.fr wrote:

 I think that ghdl is compliant with VHDL 1993 and 2002. That's modulo
 bugs, but I think that all features are implemented.  If not, do not
 hesitate to raise issues.

The issue isn't features (syntax), it's compliance (semantics).


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity tb_test0 is end;

architecture arch_tb of tb_test0 is
   signal i_s : integer := -1;
   --
   signal v_s : unsigned(7 downto 0);

begin
   -- Here it won't have any error during simulation, but it should
   v_s = to_unsigned(i_s, 8);
   --
end architecture arch_tb;

david_koontz@Macbook: ghdl -a tb_test0.vhdl
david_koontz@Macbook: ghdl -e tb_test0
david_koontz@Macbook: ghdl -r tb_test0
david_koontz@Macbook: ghdl --version
GHDL 0.31dev (20132311) [Dunoon edition]
 Compiled with GNAT Version: GPL 2013 (20130314)
 GCC back-end code generator
Written by Tristan Gingold.

This is a noncompliant VHDL design description (yet it ran without error):

From numeric_std:

  -- Id: D.3
  function TO_UNSIGNED (ARG, SIZE: NATURAL) return UNSIGNED;
  -- Result subtype: UNSIGNED(SIZE-1 downto 0)
  -- Result: Converts a non-negative INTEGER to an UNSIGNED vector with
  -- the specified SIZE.

Section 3
Types

 ...
A type is characterized by a set of values and a set of operations. The set of 
operations of a type includes the explicitly declared subprograms that have a 
parameter or result of the type. The remaining operations of a type are the 
basic operations and the predefined operators (see 7.2 ). These operations are 
each implicitly declared for a given type declaration immediately after the 
type declaration and before the next explicit declaration, if any.

A basic operation is an operation that is inherent in one of the following:

-- An assignment (in assignment statements and initializations)

-- An allocator

-- A selected name, an indexed name, or a slice name

-- A qualification (in a qualified expression), an explicit type conversion, a 
formal or actual part in the form of a type conversion,  or an implicit type 
conversion of a value of type universal_integer or universal_real to the 
corresponding value of another numeric type


 

The implicit type conversion of universal integer to natural should fail.

 
 7.3.5 Type conversions

 ...

If the type mark denotes a subtype, conversion consists of conversion to the 
target type followed by a check that the result of the conversion belongs to 
the subtype.

...

In certain cases, an implicit type conversion will be performed. An implicit 
conversion of an operand of type universal_integer to another integer type, or 
of an operand of type universal_real to another floating point type, can only 
be applied if the operand is either a numeric literal or an attribute, or if 
the operand is an expression consisting of the division of a value of a 
physical type by a value of the same type; such an operand is called a 
convertible universal operand. An implicit conversion of a convertible 
universal operand is applied if and only if the innermost complete context 
determines a unique (numeric) target type for the implicit conversion, and 
there is no legal interpretation of this context without this conversion. 

 

So the check that the result of the conversion belongs to the subtype isn't 
performed.  (And this is a run time check).

(And there is no TO_UNSIGNED (ARG: INTEGER; SIZE: INTEGER/NATURAL) defined in 
package numeric_std, leaving no legal interpretation without implicit 
conversion.  The inner most context is defined by the interface declaration 
used for the association list for the arguments to TO_UNSIGNED.)

Further, during simulation of the equivalent process statement for the 
offending concurrent signal assignment statement, the TO_UNSIGNED subprogram 
call involves the elaboration of the parameter interface list of corresponding 
subprogram declaration (See 12.5 Dynamic elaboration).

And this one of those issues of the category that the standard does not convey 
clearly, the information being spread among multiple clauses.

https://sourceforge.net/p/ghdl-updates/tickets/4/
Subtype compatibility check of an implicitly converted universal integer not 
performed during dynamic elaboration

I find these using ghdl as a reference when checking other VHDL tools.  I'll 
dig around I might have 3 or 4 more stuck in mailboxes.  All in all ghdl 
acquits itself quite favorably.

There's also around 190 compliant test cases that fail and some number of 
non-compliant tests cases that also fail.  And every last one of them needs a 
bout of VHDL lawyering to determine the validity of the test cases and results. 
 (Although those with access to say Modelsim can usually at least tell whether 
something should fail or not, just not why without the research).



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org

Re: [Ghdl-discuss] Seeking comments on my cloud based verification ide

[David Koontz]

On 23 Dec 2013, at 8:40 pm, tging...@free.fr wrote:

 I think that ghdl is compliant with VHDL 1993 and 2002. That's modulo
 bugs, but I think that all features are implemented.  If not, do not
 hesitate to raise issues.


entity label_test is
   generic (MODE: natural range 0 to 1 := 1);
end entity;

architecture fum of label_test is
begin
if_label:
   if MODE = 1 then
   end if;
end architecture;

david_koontz@Macbook: ghdl -a label_test.vhdl
label_test.vhdl:8:16: 'generate' is expected instead of 'then'
ghdl: compilation error

However:

entity no_label_test is
   generic (MODE: natural range 0 to 1 := 1);
end entity;

architecture fum of no_label_test is
begin
   if MODE = 1 then
   end if;
end architecture;

david_koontz@Macbook: ghdl -a no_label_test.vhdl
no_label_test.vhdl:7:4: a generate statement must have a label
no_label_test.vhdl:7:16: 'generate' is expected instead of 'then'
ghdl: compilation error


Normative BNF is described with a left-recursive rule.

0.2.1 Syntactic description

The form of a VHDL description is described by means of context-free syntax, 
using a simple variant of backus naur form; in particular:

 ...

f. Braces enclose a repeated item or items on the right-hand side of a 
production. The items may appear zero or more times; the repetitions occur from 
left to right as with an equivalent left-recursive rule.
 
1.2.2 Architecture statement part

The architecture statement part contains statements that describe the internal 
organization and/or operation of the block defined by the design entity.

 architecture_statement_part ::=
  { concurrent_statement }

  ...
9.7 Generate statements

A generate statement provides a mechanism for iterative or conditional 
elaboration of a portion of a description.

 generate_statement ::=
 
generate_label :
 generation_scheme generate

 [ { block_declarative_item }
 
 begin]
 { concurrent_statement }
 
 end generate [ generate_label ] ;

 generation_scheme ::=
  for generate_parameter_specification
| if condition

 label ::=  identifier

 ...

 ---

And here you'll note that a generate_label is not optional.  In left recursive  
described BNF a lookahead of one is sufficient to tell this is not a generate 
statement.

If we look at Section 9, Concurrent statements, the normative BNF:

 concurrent_statement ::=
   block_statement
 | process_statement
 | concurrent_procedure_call_statement
 | concurrent_assertion_statement
 | concurrent_signal_assignment_statement
 | component_instantiation_statement
 | generate_statement


We see that generate is the last choice (alternative rule).  Finding the 
keyword if instead of a label is sufficient to distinguish the current 
statement is not a concurrent statement, and it is not a generate statement in 
particular.

(And you can expand all the rules to demonstrate this, believe me it has been 
done before).

The error messages for no_label_test are in error.

While the parser for ghdl has the appearance of being handwritten this can be 
an issue in older versions of Bison, where the ability to specify an error 
associated with a non-terminal rule (concurrent_statement) wasn't available, 
effectively complaining about the last production (generate_statement).  That 
isn't the case here.

The error here is in Parse_Generate_Statement in parse.adb, not rejecting the 
rule generate_statement when the first production (label) does not match. 

Instead of Error_Msg_Parse (a generate statement must have a label); 
generate_statement should be rejected.

The actual error is in procedure Parse_Concurrent_Statements in parse.adb, the 
structure, treating a label as an attribute of a named object (and a generate 
statement is no (5.1, Attribute specification the rule for entity_class).

Line 5185:
when Tok_If
  | Tok_For =
   if Postponed then
  Error_Msg_Parse
('postponed' not allowed before a generate statement);
  Postponed := False;
   end if;
   Stmt := Parse_Generate_Statement (Label, Loc);

A label is a named entity.  (See 5.1 entity_class again).

A label is only required for generate statements (9.7 above, also see 12.4.2 
Generate statements (elaboration of generate statements) for why.

Treating a label as an attribute is benign every where but here because a 
generate statement is not a named entity, saying the fix should be in 
Parse_Generate_Statement.  (And ghdl isn't the only VHDL tool that parses 
labels as prefix attributes in all cases).

You could also note that without the required label the bit about postponed is 
in error as well.  Also a case of inventing a problem not in evidence.

(And about now this feels reminiscent of Il Duce's six hour 1934 radio 
broadcast 

Re: [Ghdl-discuss] Seeking comments on my cloud based verification ide

[David Koontz]

On 23 Dec 2013, at 4:40 am, Neeraj Yadav neer4j.iit.de...@gmail.com wrote:

 I have made a small cloud based verilog/vhdl simulator which uses GHDL
 and Icarus for VHDL and Verilog respectively.
 
 http://www.tarangeda.com
 
 I want comments of ghdl developers, anything you want to say.

Makes a great argument for binary distribution under the Affero GPLv3.  As 
Tristan noted earlier a binary work comprised of gcc and a ghdl front end the 
gcc compiler is distributed under the terms of the GPLv3, which allows adhesion 
to the Affero GPLv3.  

Clause 13 of both allow distribution under the Affero GPLv3, which could be 
used to require corresponding source distribution for any remote network 
interaction (cloud usage). It effectively means you'd be required to build the 
versions you use for your cloud service as opposed to using a binary 
distribution with such additional terms adhesion.  

I'd personally use those clause 13s for a binary distribution of the composite  
or aggregate work (a gcc version of ghdl).  The affect is to remove the ghdl 
developer from directly being a target for support requests from users of a 
business such as yours.  Additional terms might include limitations on 
liability and suitability for use.

The ghdl mcode version is distributed solely under the the GPLv2.

Other than business issues of ratios of free users and the ability to make 
money with your site one could wonder about We use and promote open source 
software when that promotion is limited to links on icons at  the bottom of a 
page.

Further your privacy policy on Protection of your data doesn't appear intended 
to extend to design files.

Your 'cloud' service doesn't seem to have a strong value proposition over using 
ghdl, icarus and say gtkwave separately.  The added value is the web interface. 
 (I'd be personally curious how fast (responsive) your waveform viewer is).  It 
would seem likely as a business cloud  EDA services using open source software 
is ripe for easy competition in particular when one of those open source links 
poitd to Codiad.

Simulation seems a bit narrow a focus for a business model.

 Plus I have a few questions also
 1. Do people use ghdl professionally, or is it still far from any
 professional use(I heard this on comp.arch.fpga)

You've seen two people (so far) comment that they use ghdl professionally.  
You'll find there are more.  Their use would be predicated on knowing the 
limitations of ghdl and avoiding problems.  That isn't to say any user could 
use it professionally.

As far as I can tell, ghdl isn't fully compliant with the VHDL Standard (IEEE 
Std 1076-1993, -2002 or -2008).  Off hand as far as marketable 'product' 
distinctiveness ghdl has none.  While Tristan doesn't share his plans for ghdl 
(his original release plan is badly dated), my interest is primarily in 
achieving full -1993 standard compliance.  The Brians are driven by insuring 
platform availability.  

There are currently 5 active ghdl contributors only tugging slightly in 
different directions.  The effort could use more still.  None of those are 
focused on supporting an effort such as yours, and currently only an admin can 
set priorities. Disagreements might tend to effectively lessen the contributor 
resource pool.  (The unpopular guy waving the baton and marching down the 
street needs to look over his shoulder to see if anyone is actually following).

Also being involved in several other VHDL tool development efforts, the things 
that ghdl isn't compliant with the LRM over are a usually a common set of 
issues that appear to point to weaknesses in how well the IEEE standard conveys 
 requirements.

 2. Is it okay the way I am using ghdl on my site?Are there any license
 restriction etc?

I'm not aware of any licensing terms for ghdl that are in conflict with your 
usage (a personal opinion only).  That sounds like something for which you 
might seek legal counsel.

As the GPL says, you aren't 'conveying a covered work', unless you are 
providing download access to elaborated (executable) VHDL models.  (The ghdl 
runtime library is released under the GPLv2, apparently requiring distribution 
under the terms of the GPL).  Again, you might want to seek legal counsel.

 I also want to contribute to GHDL, I need someone to give me a clear
 idea how far ghdl from say a OEM version of ModelSim?

There are obvious limitations on ghdl.

It doesn't have the an interactive shell for simulation (run/stop/step, save 
restore).

It doesn't have the ability (currently) to select signals saved to a waveform.  
This likely has a performance impact (and is something Tristan has indicated 
support for in the past).

It isn't a dual HDL front end system.  You're web site can't do mixed HDL 
models using ghdl.

It's not a GUI based tool (and frankly enclosing it with a web interface 
doesn't make it one).

It's utility for co-simulation is limited. (ghdl also doesn't support 
specification of a resolution limit for 

Re: [Ghdl-discuss] Cross building/configure for GHDL

[David Koontz]

On 22 Dec 2013, at 6:58 am, Martin Strubel hack...@section5.ch wrote:

 Now, pondering about the clean top-down way cross-compile-approach, I
 think this would turn out in quite a nightmare, at least for mingw.
 Obstacles:
 The mingw runtime isn't part of GCC, neither is the win32API, and making
 it build inside the 'unified' directory structure of gcc is a big
 question mark. GHDL needs them to build though.
 So this will turn into a multi pass compilation dance anyhow:
 - Build native bootstrap toolchain to use for further compilation
 - Build mingw compiler with ADA support, first pass
 - Build supporting runtime/win32api with mingw
 (-) Build mingw with ADA and VHDL, second pass
 
 (-) is yet missing, the current development build procedure to weld a
 cross ghdl backend against the mingw cross compiler is still hacky and
 not tested in a sandboxed build environment.

From Drangon Zhou's scripts I kind of gathered that changes might be a 
nightmare and that these would either be a patch against a particular gcc 
distribution or require gcc developer acquiescence and introduction (which 
might not be forthcoming for a marginal 'market').

 But good news so far is that the current ghdl-update sources compile
 just fine in native and cross mode (thumbs up for Brian). So allow me
 some time to come up with some patches that don't look like a bad hack :-)

I think I managed not send a snarky post saying you could do all the fiddling 
at the translate/gcc/dist.sh script level, which would have the saving grace of 
not requiring someone to verify your changes don't affect any other ghdl build 
method, but from Tristan's post he is apparently volunteering.  

The big question is whether or not a cross compile target can be generalized, 
and it likely can be, EXE suffixes aside.

And I take it you are aware libgrt.a is GPLv2?  The implication being 
distributed executable models are GPL'd.   There's a ghdl-discuss thread from 
April 28, 2010, where Tristan says he didn't anticipate someone delivering 
executable models, maybe he'll bend to an LGPL.













___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Cross building/configure for GHDL

[David Koontz]

On 22 Dec 2013, at 8:22 am, Rene Doß d...@gmx.de wrote:

 Iam back again,
 
 I miss the output file?!! Also the option -wave is unknown.


--wave ?


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] configure for GHDL OS X

[David Koontz]

I've  also built the gcc version of ghdl for OS X (10.8/10.9/10.9.1) see

https://sourceforge.net/p/ghdl-updates/wiki/OS%20X%20gcc%20ghdl%20build%20instructions/

Instructions for building GHDL (version 0.31dev) with GCC4.8.2 on OS X 10.9

This could likewise go into a makefile with the exception that wget isn't 
native to OS X. 

I'll be making a binary release after a bit of testing and coming up with a 
README describing how the two versions of the GPL interplay (gcc-4.8.2 is 
released under GPLv3).  No fancy packages seem warranted with Apple's 
Gatekeeper and the lack of an actual App.

I may build a relocatable gcc/ghdl before actually releasing. Turns out ghdl 
doesn't find ghdl1 the way it's built. (any gcc version of ghdl).

Where ghdl1 is found in :

/opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/gcc.4.8.2/ghd1

for gcc build PREFIX = /opt/ghdl/gcc-4.8.2

move ghdl to somewhere else and it still expects:

david_koontz@Macbook: ghdl -a fault_gen.vhdl
ghdl: installation problem: 
/opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1 not found

It's hard coded in drvdir/default_pathes.ads:

   Compiler_Gcc   : constant String :=
 /opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1;

Which begs the question as to whether gnat's OS_LIB.Locate_Exec_On_Path 
swallows relative paths (see ghdldrv/ghdldrv.adb).

(dependent on something called Normalize_Pathname, which gets the current 
working directory so presumably does support relative paths).

(part of gnatlib, both in gcc-4.8.2/gcc/ada/s-os_lib.adb)

Also the path to the vhdl libraries is given hardcoded in 
drvdir/default_pathes.ads:

   Prefix : constant String :=
 /opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib/;


Which doesn't result in an executable being searched for and can be specified 
with GHDL_PREFIX in your environment.

(see ghdldrv/ghdllocal.adb) as well as a  CLI arg (--PREFIX=path) for -a (and 
presumably -e, -c, ...) (see options.adb)

It'd be nice if Prefix could be relative too.

The rest of gcc is supposed to use relative paths.

 --

There's also directions for building mcode versions for OS X or a 32 bit Linux, 
see

https://sourceforge.net/p/ghdl-updates/wiki/build%20mcode%20ghdl/

(And it's a shell script that can be customized for either OS X or Linux.)



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Cross building/configure for GHDL

[David Koontz]

I got curious  and looked around for a mingw  build environment for a cross 
compiler that would lend itself to building ghdl.

It turns out Debian has mingw Linux hosted build environments using gcc-4.6.3 
and -4.7.2. You'd expect a 4.8.2 based mingw soon.

Looking a little further shows Drangon Zhou on SourceForge has built (as of 9 
December 2013) a mingw-w64 cross compiler using gcc-4.8.2.

All the scripts he used to build are here:
https://sourceforge.net/p/mingw-w64-dgn/code/HEAD/tree/trunk/
(r272), you can download a snapshot, around 57KB, no real documentation 
otherwise.

An as Brian points out trying to find recent documentation seems hard. 

Commercial support for mingw appears to be stalled at a gcc release version 
still under the GPLv2, although I found someone distributing 4.7.0.  I found 
one company sponsored by Microsoft who doesn't even distribute a copy of the 
GPL with binaries.

There's also an Arch Linux mingw-w64-gcc 4.8.2-4 
(https://www.archlinux.org/packages/community/x86_64/mingw-w64-gcc/)



On 18 Dec 2013, at 10:59 pm, Brian Drummond br...@shapes.demon.co.uk wrote:

 On Wed, 2013-12-18 at 05:20 +0100, tging...@free.fr wrote:
 Hello,
 
 So the question is whether or not specifying linkers and assemblers
 belongs in these, and I'd be inclined to think not.  The
 commentary at the beginning of Makefile.in tells the story.
 (There's also this process model of asking yourself the question
 as to why Tristan doesn't have the facility for doing so already
 expressed).
 
 The LD and AS spec to ghdl_gcc I hacked in should definitely be
 revisited. But it appeared to me that, since cross-compiling support
 was
 not in there, they were hardcoded in translate/ghdldrv/ghdldrv.adb to
 'as' and 'gcc'. For the proper cross ghdl, it would make sense to use
 the machine prefixes for as/gcc.
 
 Clearly, I have never thought about cross compilation for ghdl.
 
 Initially, I thought there were no case for that, but in fact there are
 a few ones, as you mentioned.
 
 GCC handles cross compilation, so you have to modify Makefiles using
 other front-end examples.  And yes, because ghdl doesn't use gcc to
 assemble, and invoke it to link, you have to modify that.
 
 For what it's worth, I have built gcc as a cross compiler. Building gcc
 is frighteningly fragile at best; doing something outside the mainstream
 considerably more so, and building cross with Ada enabled is a more
 lonely path. There is a lot of information out there; much of it
 obsolete and (for that reason) mutually contradictory. Just to add to
 the confusion, here is some more (with Ada, but for a different
 target...)
 
 http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/download
 
 And actually this needs updating in two respects : (a) building for
 4.8.2 and using the config/download_prerequisites script instead of
 messing around with gmp, mpc, mpfr.
 
 The basic approach should still be valid : 
 script it for repeatability, 
 separate builddir so it can be deleted if you need to start over
 build native first,
 then build binutils cross
 then build compiler cross
 then build RTS, any other libs cross
 
 Also the AVR-Ada project has quite a comprehensive script as part of its
 source dist, that automates the process (for their purposes!) 
 https://sourceforge.net/projects/avr-ada/files/avr-ada/Source%20Dist/
 which may be a useful starting point.
 
 Any other useful resources?
 
 - Brian
 
 
 
 ___
 Ghdl-discuss mailing list
 Ghdl-discuss@gna.org
 https://mail.gna.org/listinfo/ghdl-discuss


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Cross building/configure for GHDL

[David Koontz]

On 18 Dec 2013, at 1:42 am, Martin Strubel hack...@section5.ch wrote:

 Now for something completely different:
 I've been messing around with the build process a few months ago to
 enable cross compilation for GHDL. Since you seem to rather have the
 global picture in current development, I'd like to hear your opinion
 about such a feature (of course, other's opinions are welcome).
 Maybe we should open the discussion on another page, but let me quickly
 explain the motivation: I sometimes need to hand out a simulation that
 needs to co-simulate with something else, both running on a Windows
 i386. For convenience, and also to avoid the mcode path, I'm building
 all on a Linux box using the mingw32 cross compiler.
 Likewise, one could build simulations for a little ARM cluster, question
 is, whether such a madness makes sense.
 
 The cross-support would require:
 - Some changes to the build procedure
 - Some Path patching in the ghdldrv section (I've added flags like
 --AS=... -LD=... to allow specification of the cross toolchain)
 - Quite some testing, thus: work :-)

 
 Currently I've just got an ad-hoc patch for the svn150 variant, but the
 full cross compile support would likely require some ./configure
 overhead to generate the Makefiles. So maybe -- apart from the cross
 funkyness -- it would help the build procedure in general. Sorry if this
 has been discussed before (I didn't google up the history..).
 
 Any thoughts?

Ya, thoughts. 

Collectively I refer to these as 'Who Bells the Cat?' after snarky things 
Robert Heinlein used to put in some of his novels about nice ideas and who does 
the actually work (a pun about division of labor).

If you look in the gcc-X.X.X/vhdl subdirectory for the ghdl supplied VHDL 
language front end you'll find various configurable files use in building the 
ghdl front end, config-lang.in, lang.opt, Make-lang.in and Makefile.in. There's 
also lang-specs.h and lang-options.h.  These are all produced along with the 
appropriate Ada and C source code from the ghdl source distribution.

They are used to communicate how to build the ghdl front end to the gcc build 
process. You'll notice none of these specify tools used to build the ghdl front 
end to gcc until you hit Makefile.in where yo'l find bindings for macros MAKE, 
MV, RM, RMDIR, ECHO, LN, CP, AR, MKDIR, CHMOD, true, pwd, and cd, which are all 
apparently required.

So the question is whether or not specifying linkers and assemblers belongs in 
these, and I'd be inclined to think not.  The commentary at the beginning of 
Makefile.in tells the story. (There's also this process model of asking 
yourself the question as to why Tristan doesn't have the facility for doing so 
already expressed).

I'm more inclined to believe the proper place for specifying build chain tools 
is through gcc-X.X.X/configure, etc.  And likely it should be a matter of 
configuration.

My first inclination is that if you have the urge to put specific tool 
information in source provided by ghdl that there is likely some confusion over 
multistage builds. And I could be wrong, I'm far from being a current expert on 
building gcc.

The point of all this is that I wouldn't (personally) make a rush to judgement 
on accepting the content of your patches to cross compile without looking at 
the issue from a gcc perspective.  As Brian has pointed out in the past, there 
are usually three ways of doing something when building gcc.  (Funny, I can 
only usually find two). It's likely  a top down gcc issue and not a bottom up 
from ghdl issue.

And should the solution properly fall with in build setup in the gcc build 
environment you've already seen Brian's and my feeble attempts to at describing 
how to build the VHDL front end into gcc using configure and make arguments 
(should you have perused the Wiki).

Strictly speaking building on a specific platform is a gcc build issue.  ghdl 
shouldn't preclude building the vhdl language front end from source for 
compatible gcc platforms.  (And you may or may not have noticed the big patch 
Tristan put in last night including assembler directives for specific 
platforms, which addresses platform compatibility).

I'd personally be concerned that making platform tool selection decisions in 
the wrong place might preclude ghdl from every being accepted formally as a 
language front end for gcc. The likelihood of which today is bounded by 
popularity - driven by language support and features, and compatibility with 
the gcc build process - including regression or release testing.  These two 
things we can work on.  Otherwise we shouldn't be hasty about diverging 
potentially from 'the one true way' to build gcc.  

And you'll find the gcc-X.X.X/configure script already contains various 
'special consideration' for various platforms.  Any reluctance on the part of 
the gcc developers would likely stem from ghdl not being the 'official' vhdl 
language front end as well as viability of target platforms.

I'd 

Re: [Ghdl-discuss] gcc 4.8.1

[David Koontz]

On 16 Dec 2013, at 5:14 am, Rene Doß d...@gmx.de wrote:

 red@linux-x6qx:~/ghdl/code/translate/gcc ./dist.sh
 ./dist.sh: Zeile 90: ghdl-0.31dev/vhdl/Makefile.in: Datei oder
 Verzeichnis nicht gefunden
 red@linux-x6qx:~/ghdl/code/translate/gcc
 
 Some german words are in the output. I translate
 
 Zeile 90 -  line 90
 
 Datei oder Verzeichnis nicht gefunden   - file or directory not found

dist.sh should have the argument sources ./dist.sh sources

There is no vhdl directory until the archive is constructed during ./dist.sh 
sources

I get the very same error (in English mind):

%% dist.sh
dist.sh: line 90: ghdl-0.30dev/vhdl/Makefile.in: No such file or directory 

While
%% dist.sh sources

produces a ghdl-X.XXdev.tar.gz archive in that same directory (X.XX replaced by 
the actual version number).

 Also the output of my compiler. There is ready for ada.

I'd make sure the Ada front end is actually installed and isn't 'optional'

Try 

%% gnatmake --version

or 

%% gnat --help

Which will tell you whether gnat is present.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] gcc 4.8.1

[David Koontz]

On 16 Dec 2013, at 8:12 am, Rene Doß i...@dossmatik.de wrote:

 Hallo David,
 
 First, I thought you have forgot to commit a file in mercury.
 
 ./dist.sh sources
 
 runs currectly without any bad comment.
 
 After I have the file ghdl-0.31dev.tar.bz2 im my directory.

Good.


 I had better read in the README.
 
 Question 1:  What makes the additional command sources?

It's a command line option to dist.sh

See the test at line 425 of dist.sh 
With no arguments it simply tries to do_Makefile (and fails).  Tristan would 
have picked the value sources in anticipation of adding more command line 
options.

(And I'd swear there used to be other command line options, years ago.)


 Question 2: I think my last ghdl installation had object files inside
 the installing zip.
 Can you say me what is the next step?

Brian says I lost his wiki page on ghdl-updates, it's now restored. See 

https://sourceforge.net/p/ghdl-updates/wiki/build%20ghdl%20from%20source%20on%20Linux/
Instruction for building GHDL (version 0.31dev) with GCC4.9.2 on Linux.  You 
should be at step 5) now.

You may have to backtrack to see where 'source' is, it's the directory where 
gcc-4.8.2 has been extracted from the downloaded archive.

 
 René
 
 Open suse come with:
 
 %% gnat --help Which will tell you whether gnat is present. 
 
 red@linux-x6qx:~/ghdl/code/translate/gcc gnat --help
 GNAT 4.8.1 20130909 [gcc-4_8-branch revision 202388]
 Copyright 1996-2013, Free Software Foundation, Inc.
 
 List of available commands
 
 gnat bind   gnatbind
...
 gnat xref   gnatxref
 
 All commands except chop, krunch and preprocess accept project file
 switches -vPx, -Pprj and -Xnam=val
 
 gnat: Unknown command: --help

You got gnat, Ada is installed.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

[Ghdl-discuss] How to build Linux ghdl mode version, where to find a binary distribution.

[David Koontz]

The build script is derived from building ghdl_mcode on OS X and uses an svn 
download to obtain
ghdl from the gna.org repository.

It expects a gnat and gcc in the search path that can generate a 32 bit 
executable without modifying Makefiles.  The mcode version of ghdl is a 
compiled program that performs direct compile (translating IR representation to 
macros of i386 instructions) just in time (the elaboration phase is collapsed 
into the run (-r) command).

The script will download (checkout ro) a specific svn revision of ghdl from 
gna.org (-r150) into a subdirectory ghdl in the directory it is invoked.

You could note that it builds ghdl in place, where the svn download is invoked 
by executing the script.  By default it removes everything superfluous to ghdl 
mcode mode unless the command line option --keep-build is given.

Installation consists of linking the man page and the executable (as ghdl) into 
/usr/local (man/man1 and bin).  The installation portion of this script is 
currently commented out.  The actual executable is  
ghdl/translate/ghdldrv/ghdl_mcode and it's linked as 'ghdl'.  The directory 
tree structure of the build/install directory is necessary for ghdl (mcode 
version) to find the VHDL libraries.

The place to invoke any patches would be right after the svn operation.

A binary distribution can be created by archiving the build/install directory 
after it's built and stripped (no --keep-build CLI option).

Installation consists of unarchiving  the build/install tree in the 
corresponding place.  (Absolute paths are compiled in).  After which the 
executable is linked (ln -s /opt/ghdl/translated/ghdldrv/ghdl_mcode 
/usr/local/bin/ghdl).  The same is done for the man page at the top of the 
build/install tree (e.g. ln -s /opt/ghd/docl/ghdl.1 /usr/local/man/man1/ghdl.1).

The script expects svn gnat and gcc in your search path as well as other 
executables, (see the script itself) and isn't particularly bullet proof or 
robust.  Any error upsetting where the script thinks it is could have 
catastrophic consequences.
I simply checked to see if it would build and clean out the build/install tree 
under lubuntu 12.04 with gcc-4.6 (gnat) and gcc-4.7 (gcc).

Creating a ghdl_mcode.tar.bz2 file with absolute paths to /opt/ghdl took 
2,080,568 bytes.  I can send that or make it available to anyone who is 
interested in having a binary copy built there (note the script).  The tail end 
of the script has commented out commands for creating links for the executable 
and man page in /usr/local and these are relocatable  as long as they show up 
in your search path/man path.  

There are no requirements on having a particular version of gcc available to 
use the mcode version.  
Note that in the /opt/ghdl/doc/ghdl.html file when directing attention to the 
windows version, generally that can be read to mean 'windows version or other 
ghdl mcode version'.

The mcode version of ghdl doesn't produce object code files nor does it support 
foreign object code import.  The -e (elaborate) command isn't necessary in an 
mcode version, but doesn't cause any harm.  Elaboration actually occurs during 
the -r (run) command, jit.  In general pre-existing Makefiles are likely usable 
with the mcode version, simply requiring re-analysis before running (and it's 
quick).

https://dl.dropboxusercontent.com/u/25980826/ghdl_mcode_linux.zip  
(the binary, 2,092,435 bytes, GPL license, binary to install in /opt/ghdl, 
build_distribution script, and README)

There were no source code no modifications  required to generate this ghdl 
mcode version.

Version and warranty information can be found by running ghdl --version (there 
is no warranty whatsoever, nor is there a customer/vendor relationship implied 
herein).

The binary distribution was built using the build_distribution script.  It was 
tested using a VHDL implementation of the Digital Encryption Standard.  No 
regression testing has been performed.

Try it, it's fast, small and swallows big designs that cause the gcc version of 
ghdl to grind slowly or runout of memory.  It does this because it performs to 
optimization on the jit image in memory.





___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL possible bug: 1-cell array initialization

[David Koontz]

On 29 Nov 2013, at 5:39 am, Adrien Prost-Boucle 
adrien.prost-bou...@laposte.net wrote:

 - The genarated circuits are intended to be synthesizable (and I
 synthesized many other generated apps, analyzed hardware resource usage,
 built resource usage estimators in the HLS tool, successfully executed
 the designs on FPGA). So I don't generate wait statements, it's too easy
 to make something not synthesizable with these.

I was speaking of equivalent processes to the concurrent statements, which is 
how they get simulated.  Not implying something you specify in your design 
description.




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL possible bug: 1-cell array initialization

[David Koontz]

On 29 Nov 2013, at 8:39 am, Brian Drummond br...@shapes.demon.co.uk wrote:
 
 So I think this one is worth reporting on
 https://gna.org/bugs/?group=ghdl
 with the note that the mcode version bypasses gcc's memory-hungry
 optimisation passes.
 
 (Makes me wonder if it's possible to build the mcode version on Linux?)

I have built the mcode version on Linux (32 bit).  Note you can't use foreign 
objects (subprograms) with it.  It might be worthwhile in this case.  Adrien's 
generated coded doesn't appear to benefit from optimization either.  It also 
may be worth making an x86_64 version of the mcode ghdl.  (Need to tinker with 
around a half a dozen or so opcode replacements and uncouple i32/i64 size from 
things like simulation time). There's a mapping of IR constructs to target 
machine 'macros' of opcode instructions.  There's still a SPARC v8 instruction 
set creeping around in there too.

There appears to be little use for optimization other than really big process 
statements or process statements filled with variable manipulation.  Signal 
transactions performance is defined by the simulation cycle. 

Nick's llc compile in --native mode of fsm_test just crossed 2 hours 30 minutes 
of CPU time and is up to 2.75 GB of memory.  We seem to have a time/memory 
trade off here.  The bitcode version (akin to ghdl mcode) took around 26 
minutes to 'compile', versus the two minutes to elaborate and run under the 
ghdl mcode version.

(You could also note that an mcode version doesn't chase gcc releases, and I 
can imagine adding foreign object loading.) :-)


 Now the other example appears to elaborate successfully
 ghdl -a tb.vhd
 but the alleged problem is that it fails with (others = (others =
 '0')) to initialise ... I'm not clear ... is this right?
 constant in_vectors : invec_type;
 constant out_vectors : outvec_type;
 
 My problem with that file is that the current initialiser for
 out_vectors is an aggregate on a single line, 2588734 characters long!
 
 My text editor won't display it! I tried pasting it into my email client
 and had to kill/restart it! So I have my doubts whether ghdl isn't
 perhaps truncating it or (unlikely) failing and exiting silently.
 
 I would like to see this file recreated with a more sane line length.
 
 - Brian

I posted on the line lengths too.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL possible bug: 1-cell array initialization

[David Koontz]

On 29 Nov 2013, at 12:34 pm, Adrien Prost-Boucle 
adrien.prost-bou...@laposte.net wrote:

 First, for each oy you who tried to work on my vhd files, I'm ver sorry
 about the impossible line lengths!!! Indeed vhd files need to remain
 humanly readable and editable (I've myself read and manually corrected
 many of the huge vhd files I generate, with my favorite editor (geany)
 without any problem... but as I'm somewhat still the only developer (and
 user) of my tools I tended to forget basic formatting rules, sorry xD)
 
 Tomorrow (France time) I'll edit my testbench generator and re-generate
 a human-readable and editable tb.vhd.
 
 
 On Thu, 2013-11-28 at 20:18 +, Brian Drummond wrote:
 
 Again another data point: Editing out both the aggregates and replacing
 them with (others = (others = '0')), tb analyses, elaborates and
 runs fine - in under a second for each phase.
 
 So I see no evidence whatsoever for a problem with initialising these
 large arrays with (others = (others = '0'));
 and plenty that the ridiculous line lengths were causing problems; but
 not necessarily for ghdl.
 
 Actually, I meant _appending_ this (others = (others = '0')) at the
 end of the values already present, not replace the entire line. Like
 this:
 
  ... := (
X00, X01, ..., XAB, (others = (others = '0'))
  );

An others choice can always be included even if you have full coverage for  
positional associated choices in your aggregate being assigned to a composite 
type.  It's a VHDL feature likely intended for the the sort of use you want to 
put it, blindly giving an others choice regardless of the number of elements in 
the composite type.

Someone saw your need when defining VHDL.  I thought one of the cases I tried 
and showed in my first post showed this working for the 0 to 0 array.

 Originally, this was the easiest solution to make the array
 instantiation syntactically correct when there is only one cell. So this
 (others = (others = '0')) addition isn't meant to actually fill any
 cell with any '0'. It is meant to remain unused, and unuseful, except
 for making ghdl parse the vhdl code in the specific case where the array
 has only one cell.
 (yes this purpose doesn't deserve all the attention of ghdl-discuss...
 but the result (crash) does)
 
 I'll send a patched human-formatted tb.vhd tomorrow (in ~20h because
 sending mails from my personal email address is refused by laboratory's
 network...)
 
 Or this others thing could be appended to my currently huge line like
 this:
 
  ... := (
X00, X01, ... 400k other values
   , (others = (others = '0'))
  );
 
 Don't know if this comma at the beginning of the line is syntactically
 correct, it sure isn't pretty, but if it works for now...

I'd try go for it.

 David, I didn't send the rest of the application because it is another
 mountain of vhdl, and because my ghdl crash happens right at analysis
 the tb.vhd file, so the rest is not needed.

It's nice we could collectively narrow down the problem.  Not sure when we 
can deliver a solution.  Nick's fsm_test elaboration generated a 40 MB object 
file.  His tool may not be ready for real use yet.  

Could you use an mcode version of ghdl if some one made a Linux version?

 My tools are under heavy development so right now, without manual
 constraints, the generated circuits tend to be unrealistic, for the
 bigger apps I use as testbenches. Making all this realistic is one of my
 top goals, to get there I use big apps, consider how they are
 transformed by the tools, observe every bit of the generated vhdl,
 launch simulations / logic synthesis / placeroute to test everything...
 work in progress.
 BTW, when manually applying transformation we can get very realistic
 circuits with my tools. It is the automatic mode that produces little
 insanities like fsm.vhd.

Found your paper 'A Fast and Stand-alone HLS Methodology for Hardware
Accelerator Generation Under Resource Constraints'
http://www-labsticc.univ-ubs.fr/~chavet/orga/HLS4HPC_2013/txt/APB_paper.pdf

http://tima.imag.fr/sls/research-projects/augh/

(I wondered what AUGH stood for - Autonomous and User Guided High-level 
Synthesis).


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL possible bug: 1-cell array initialization

[David Koontz]

On 28 Nov 2013, at 6:38 am, Adrien adrien.prost-bou...@laposte.net wrote:

 As David Koontz suggested, I chose to append others = (others = '0')
 to the list of values, and it works.
 
 Thanks a million David for your great answer. I learnt something
 useful:)
 
 HOWEVER...
 
 When I say it works, well yes it does work for some little circuits.
 For a big circuit, where my array has 369817 cells (width 8), ghdl
 rapidly eats all my system's RAM and tells me this:
 
 ghdl1: out of memory allocating 14974840 bytes after a total of
 1966264320 bytes
 ghdl: compilation error

Without knowing better that looks like it was already using 196,624,320 bytes 
of memory already and asking for 14,974,840 bytes more.

 
 It is reproducible.
 When I don't append others = (others = '0') to the list of values to
 initialize my array of test vectors, GHDL is happy.
 When I append it, GHDL makes this out of memory error.
 
 What's curious is that I have another app with which GHDL makes the same out 
 of memory
 error, but it's completely unrelated to the array of test vectors.
 Or maybe it is: this other app has a one-hot FSM with 73945 states xD
 It's an std_logic_vector(0 to 73944) who is initialized with (others =
 '0'). This FSM is a beast 745058-lines VHDL file, 12.5MB.
 For this FSM GHDL says this:
 
 ghdl1: out of memory allocating 536870912 bytes after a total of
 227868672 bytes
 ghdl: compilation error

Notice   there's a similar n=1 dimensional others statement at line 2373 in the 
process sensitive to clock:

state_cur = (others = '0');

And in the state transition process at line 289:

state_next = (others = '0');

Both of those are array sizes 3945.

 There GHDL says it fails to allocate 539MB after 230MB, which does not
 seem huge IMHO.

Notice the failure point used memory wise is close between the two different 
models, which may speak to other complexities.  It looks like you simply don't 
have enough memory.

We can actually look at fsm.vhd because you sent the source.  It has 150,235 
signals and signal elements, and it seems the ratio of size would be hard to 
imagine if it were only made up of those 539MB/150235 = 5370 bytes per signal.  
 That seems a bit high so you could wonder if there were something else going 
on with others assignment.  Perhaps those others assignments got unfolded from 
loops to flat.

 If it's of any interest, you'll find attaches this FSM (.gz 733kB).
 And Xilinx XST also makes an out of memory error on the same FSM component...
 I really want to understand why. It really seems to be related only
 to the size of the FSM state register.
 
 I totally know building a circuit with 74k states is unrealistic.
 I am only interested about it from a simulation point of view.
 Why whould a 74k-cells std_logic_vector make a compiler/simulator crash?
 And one must always know the behaviour of the tools he uses!

 
 Is it possible that this construct (others = stuff) can stress ghdl
 that much?

The allocated memory numbers being close for the two reports above say's you're 
likely running out of memory.  What you may be railing against is the amount of 
memory ghdl is using for the models.  It doesn't appear to be data space, so 
perhaps its program space.  Do you have a size for the .o file?  It might be 
interesting to disassemble it too.

Instead of the likes of:

state_next = (others = '0');

you could try:

   for i in state_next'range loop
state_next(i) = '0';
   end loop;

for those big arrays.

If that works or the amount of memory ghdl is trying to allocate goes down 
significantly perhaps Brian or I could manage to locate the code generation 
output and try optimizing it a bit for others aggregates.  No guarantees.

 Or do I have really excessive expectations with my oversized components?
 Your feedback would be greatly helpful!

I don't think they reflect hardware you'd actually build.  Wholesale setting an 
entire one hot state array that big simply because you don't do it for the bits 
set in the precursor state to the now current state seems a bit excessive.  

The if statements should be if then elsif...  The way the it is now you 
evaluate all the expressions and all but one are going to false. Using elsif 
allows you to quit evaluating after you find the current state value.  

I think a port with 2347 signals is a bit extreme (read unreasonable).

You should try in another tool environment as well, speaking of which Nick 
Gasson emailed me and after modifying his VHDL tool so it would analyze 
fsm.vhd.  He used emacs to write a test bench.  Last heard he was waiting on 
elaboration to finish so he could quit for the night.  fsm.vhd is the slowest 
analyzing VHDL design description I've ever seen ghdl swallow.  

fsm.vhd.gz is under the maximum size threshold for appending in a bug report on 
gna.org. (And I don't know whether that's a blessing or a curse).

A one hot state machine is harder to generate than something

Re: [Ghdl-discuss] GHDL built with gcc4.8.2

[David Koontz]

On 27 Nov 2013, at 4:46 am, Brian Drummond br...@shapes.demon.co.uk wrote:

 
 I have managed to get GHDL to build with gcc4.8.2 as both the compiler and 
 the sources.
 
 Instructions (README), build script and patch attached.
 
 Testing so far shows no problems, including the simple OSVVM demo.
 
 Apologies for formatting of previous message.
 I had no idea Evolution would simply cat some of the attachments (but
 not others!) instead of attaching them properly.
 
 Anyway a better home for the patch and instructions is at:
 https://gna.org/bugs/index.php?21305


Any chance of a change log (even by groups of files)?  There seems to be three 
groups of changes in this patch file.  You're OS-VVM patches, the GCC 4.8.2 
patches and other changes.

Funny, the weather today pretty much matches that of Dùn Omhain here in the 
Antipodes (where it's supposed to be summer).

Also Nick Gasson has hosted the Philip Wilsey's  VHDL tESTs (VESTs) on github) 
and reported -r150 ghdl passed 3558 of the  3759 no error (analyze) tests with 
201 failures.  There are tests that are supposed to fail during elaboration or 
simulation not included in those numbers.  I think I saw something that would 
knock at least one of those failures out in your patch.   See 
https://github.com/nickg/vests  (and this is a case of having to know the 
path).   GPLv2 which is why they're in a separate repository.


Nicks script for running the analyze VESTs against ghdl:

https://github.com/nickg/nvc/blob/e874111ab5a5fe9d0cbbc80e6caf801473297c12/test/run_vests.rb

I'm not interested in getting stuck chasing gcc releases but could be persuaded 
to work on VHDL language compliance issues and testing. I spent a week or so 
screening ghdl bug reports and trimming them down, added a few more. (VHDL 
Lawyering when done properly is labor intensive, too bad we don't get paid like 
lawyers).

After suitable testing I could probably manage to enter the current spate of 
patches into the gna ghdl archive, although I think it may be time to host a 
branch somewhere else.  Hence the interest in change logs.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] --stop-delta error when simulating

[David Koontz]

On 31 May 2013, at 9:02 AM, Jon Taylor dosad...@gmail.com wrote:

 Hi all,
 
 I am encountering a wierd error when simulating a design using GHDL, and I 
 just wanted to ask if anyone else out there has seen this before.  When I run 
 my simulations, I get this after a while:
 
 error: simulation stopped by --stop-delta
 
 I didn't start the simulations with any command line arguments.  Is there a 
 default value for stop-delta?  If so, the docs on ghdl.free.fr didn't mention 
 it... the simulations all loop forever (self-clocked processes) and do a lot 
 of non-blocking native calls and start one native thread using pthreads, if 
 that makes any difference.

From grt-options.ads, the default:

   --  Set by --stop-delta=XXX to stop the simulation after XXX delta cycles.
   Stop_Delta : Natural := 5000;





___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Debian package maintainer has retired

[David Koontz]

On 27 May 2013, at 10:04 AM, Svenn Are Bjerkem svenn.bjer...@googlemail.com 
wrote:

 Sometimes it is better to move the troubled kid out of the community. Having 
 a clean-room version of the gcc version compatible with ghdl in a location 
 where apt-get cannot touch it seems very much a way around the current 
 problem. Problem for me as a GHDL user is that building gcc in /usr/local or 
 /opt/local and then build GHDL on top of that needs a teaspoon step-by-step 
 instruction or a script. So far I am stopping any update or install on my 
 Debian which would remove GHDL. That also means I am stuck at whatever GHDL 
 version available in Debian/sid. I would really like to use OSVVM, but my 
 lack of gcc-fu prevents me from that.
 

There's Peter Gavin's ghdl PPA as a model, this one for ubuntu 12.04 and 12.10: 

https://launchpad.net/~pgavin/+archive/ghdl

Mind, it takes a leap of faith to trust someones Personal Package Archive.  
I've recently used this one to load ghdl on a lubuntu 12.10 virtual machine.

By selecting 'view package details' and expanding the packages you can access 
the contents for download and manual install.

It installed in /usr/lib/ghdl with a shell script in  /usr/bin to invoke ghdl. 

The sizes imply the 12.04 and 12.10 versions may be identical.   Someone added 
a 13.04 build while I was writing this up.


How do I create a PPA?

And it does appear it takes someone willing to bell the cat with Brian 
Drummond's OSVVM updates and the latest svn release (r150).  

I've compiled both into an OS X mcode version but don't a) have anyway to 
upload to free.fr and b) don't currently have an environment to link to 
10.6/10.5 runtime libraries (just 10.8/10.7).

I've done a Linux mcode version sometime in the last year just to prove you 
could.  It should be possible to do one with the changes easily enough.  The 
mcode version is only i386, currently  doesn't have x86_64 mappings for some IR 
constructs needing x86_64 equivalents for non-supported instructions.  

We've seen from what René Doß has done recently with foreign functions it's 
very desirable to keep the gcc version going.   I haven't built gcc versions 
recently.

From  Brian Davis and others we see the Windows mcode version could use 
updating as well.  I have no capacity to deal with Windows versions of ghdl 
whatsoever.

As a community we don't have access to any release validation mechanism used by 
Tristan prior to releases (and we've seen Windows version  problems in any 
event).   You can easily separate issues into gcc and VHDL.

I downloaded a copy of VESTs from Clifton Labs in 2006, and while the tests do 
have some errors that could use some fixes they are a superset of the last VHDL 
validation suite and also released under GPLv2.  The tests aren't available 
anymore on the web, they were found only on ftp sites and I'd like to find a 
home for them.  You can imagine they are the basis for various vendor's test 
suites.

The test suite is intended to be run using dejagnu,  has an out of date and 
not-applicable-to-ghdl test harness, and either using it or doing something 
reminiscent of the last vhdl validation suite using scripts might be in order.  
  

VESTs is intended to be extensible for those test cases you use to demonstrated 
reported problems and demonstrate fixes.  Test case coverage (depending on who 
you ask) is somewhere around 46 percent for 1076-1993.

I'd offer to screen any failures the first time playing VHDL lawyer and fix any 
broken test cases that could be fixed.  It can take hours to screen each one, 
hopefully I'm not biting off more than I can chew.  In general you need to 
check the LRMs for all supported 1076 releases.  

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

[Ghdl-discuss] vhdl - GHDL 0.29 for Windows hangs if the number of statements in a process is even - Stack Overflow

[David Koontz]

GHDL 0.29 for Windows hangs if the number of statements in a process is even on 
stackoverflow.
 

The three test cases work with the -r150 svn ghdl, plus Brian Drummond's  OSVVM 
library patch file #17858:  osvvm_for_svn_r150.patch compiling as an mcode 
version under OS X.  (gna has an outdated or otherwise invalid SSL certificate, 
I make a one time exception every time.)

If anyone can address the issue on stackexchange, feel free.

I also found something while checking the OS X mcode version. 

Converting the three test cases to one file by grabbing all the text, 
commenting out  the intervening text statements and uniquifying the behavior 
names:


helloworld.vhdl  uniquified architectures, three test cases in one source file

 use std.textio.all;

 entity hello_world is
 end hello_world;

 architecture behaviour1 of hello_world is
 begin
process
   variable l : line;
begin
   write (l, String'(Hello world!));
   writeline (output, l);
   wait;
end process;
 end behaviour1;
--The following program hangs and doesn't print anything.

 use std.textio.all;

 entity hello_world is
 end hello_world;

 architecture behaviour2 of hello_world is
 begin
process
   variable l : line;
begin
   assert false report Foo severity note;
   write (l, String'(Hello world!));
   writeline (output, l);
   wait;
end process;
 end behaviour2;
--The following program outputs the two assertions and then the Hello world! 
message.

 use std.textio.all;

 entity hello_world is
 end hello_world;

 architecture behaviour3 of hello_world is
 begin
process
   variable l : line;
begin
   assert false report Foo severity note;
   assert false report bar severity note;
   write (l, String'(Hello world!));
   writeline (output, l);
   wait;
end process;
 end behaviour3;
==

Looking in the LRM (93):

11.4 Order of analysis

The rules defining the order in which design units can be analyzed are direct 
consequences of the visibility rules. In particular:

a. A primary unit whose name is referenced within a given design unit must 
be analyzed prior to the analysis of the given design unit.

b. A primary unit must be analyzed prior to the analysis of any 
corresponding secondary unit. 
In each case, the second unit depends on the first unit.

The order in which design units are analyzed must be consistent with the 
partial ordering defined by the above rules.

If any error is detected while attempting to analyze a design unit, then the 
attempted analysis is rejected and has no effect whatsoever on the current 
working library.

A given library unit is potentially affected by a change in any library unit 
whose name is referenced within the given library unit. A secondary unit is 
potentially affected by a change in its corresponding primary unit. If a 
library unit is changed (e.g., by reanalysis of the corresponding design 
unit),then all library units that are potentially affected by such a change 
become obsolete and must be reanalyzed before they can be used again. 


IEEE 1076-1993 appears to be telling us that if I reanalyze the entity 
hello_world the previously analyzed architectures (secondary units) behaviour1 
and behaviour2 in the case of the third instance of the entity hello_world, 
should be obsolete and require re-analysis. 

underline added.

gdhl allowed any of the three to run.  

david_koontz@Macbook: ghdl -a helloworld.vhdl
david_koontz@Macbook: ghdl -r hello_world behaviour1
Hello world!

david_koontz@Macbook: ghdl -r hello_world behaviour3
helloworld.vhdl:48:8:@0ms:(assertion note): Foo
helloworld.vhdl:49:8:@0ms:(assertion note): bar
Hello world!

david_koontz@Macbook: ghdl -r hello_world behaviour2
helloworld.vhdl:29:8:@0ms:(assertion note): Foo
Hello world!


This appears to violate the directive must (emphasis added):


0.2 Structure and terminology of this document

...

Additionally, the word must is used to indicate mandatory weight. This word 
is preferred over the more common shall, as must denotes a different 
meaning to different readers of this standard.

a. To the developer of tools that process VHDL, must denotes a 
requirement that the standard imposes. The resulting implementation is required 
to enforce the requirement and to issue an error if the requirement is not met 
by some VHDL source text.

b. To the VHDL model developer, must denotes that the characteristics of 
VHDL are natural consequences of the language definition. The model developer 
is required to adhere to the constraint implied by the characteristic.

c. To the VHDL model user, must denotes that the characteristics of the 
models are natural consequences of the language definition. The model user can 
depend on the characteristics of the model implied by its VHDL source text. 

Where must means compliance is required by the tool developer.   

Admittedly this is a seldom encountered case.

Re: [Ghdl-discuss] Calling functions written in VHDL from a linked C-language-compiled binary

[David Koontz]

On 13 Apr 2013, at 9:28 PM, René Doß d...@gmx.de wrote:

 first
 
  Davids changed code works. This is nices.
 
 equiv_process:
  process
  begin
  global = get_global(2);
  wait until board_clk'event  and board_clk = '1';
  end process equiv_process:
 
 The wait reactivate the process. The changing is only valid in the next clock 
 cycle. T

You can hand craft a process statement instead, with easier control over order.

 Other question: exist an other posibilty?
 Maybe a other VHPI function type?

A little research shows that the VHPI functionality present in ghdl is the 
subset necessary to support ghdl with IVI (prior to it's transition to 
Eclipse).  You'd think that having more interactivity to foreign software would 
require the ability to interface to a fuller set of objects.  

I recall having worked in a Cadence centric engineering effort at the time VHPI 
came out and playing with it for several days, including constructing some test 
cases.   This would have been around 1997 I think.

For an idea what VHPI in full can do, you can check out section 2.6 of Peter 
Ashenden and Jim Lewis's book 'VHDL 2008 Just the New Stuff' or see sections 17 
through 23 of IEEE Std 1076-2008.  For those interested in UML descriptions see 
the IEEE-SA Supplemental Materials for 1076c-2007 
(http://standards.ieee.org/downloads/1076/1076c-2007/1076c-2007-code-vhpi_uml.zip).

Looking through the included vhpi_user.h you could definitely get the idea that 
VHPI was intended to be portable.

There are two implementations  in ghdl, one to support IVI  VPI and one for 
VHPI.  See grt-vpi.ads, grt-vpi.adb, grt-avhpi.ads and grt-avhpi.adb.  Both are 
limited subsets.

The implementation doesn't seem complete enough to extend functionality for 
what you are trying to do.  I'd consider extending VHPI in ghdl to be one of 
those things that are possible with the requisite and knowledgeable programming 
talent.  There are likely things in ghdl with higher priority.

The ability to use foreign subprograms as currently supported by ghdl is 
sufficient to support functionality provided by VHPI when limiting the scope to 
what's visible in a process statement.   You'd need to write a package 
containing enumeration conversions for types and type signaling to C and would 
be counting on sequential statements invoking function calls for order.  The 
VHDL code would be big and clumsy and would be in effect a subset of VHPI 
functionality in 'user-space'.  The effort might be better used extending 
ghdl's VHPI support although would be a wonderful learning experience.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Missing directories in SVN

[David Koontz]

On 12 Apr 2013, at 6:10 AM, Jon Taylor dosad...@gmail.com wrote:

 Woops, I guess everything is in the SVN repository after all - I didn't 
 notice the translate/ directory for some reason (I was looking for the GRT 
 code).  But the tarball does seem to be missing the doc/, libraries/, ortho/, 
 psl/, translate/ (the stuff in translate/ is in a directory called vhdl/) and 
 xtools/.  Basically it looks like the tarball is from an older realease or 
 something

The tarball is generated from a release checked out via SVN. See the top level 
README:

### Creating a source tar. ###
##

GHDL requires GCC to be compiled.  The exact version of GCC is defined in
./translate/gcc/dist.sh, in the GCCVERSION= line.  Do not try to change the
version, this may not compile or create a buggy compiler.

The GHDL sources provided on http://ghdl.free.fr do not exactly match the
files hierarchy here.  The later are used to directly build a compiler and
follow what GCC expect, while the former are used to do development and
are more logically organized.

Use the ./translate/gcc/dist.sh script to create sources to be included in GCC:
$ cd translate/gcc
$ ./dist.sh sources
# This generates a ghdl-VERSION.tar.bz2 file.

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GNAT 2012 build of latest SVN on Mac OS X 10.8

[David Koontz]

 used gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz from 
 libre.adacore.com
 
 Building was actually quite simple, and I was able to build from the
 SVN checkout, using the basic method given by David Koontz, but of
 course for x86_64:
 
 svn co svn://svn.gna.org/svn/ghdl/trunk ghdl
 cd ghdl/translate/ghdldrv
 make target=x86_64-apple-darwin
 ln -s ghdl_mcode ghdl
 make target=x86_64-apple-darwin install.mcode
 
 The result is able to analyze, but upon elaboration or run:
 
  GHDL Bug occured 
 \


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Displaying converted Integers to Real fails on amd64-machines with gtkwave = 3.3.19

[David Koontz]

On May 5, 2012, at 4:43 AM, byb...@nc.rr.com byb...@nc.rr.com wrote:

 Fixed in SVN revision 620.  Thanks for reporting this.
 
 I've also just uploaded a fixed OSX gtkwave.zip app bundle (candidate for 
 3.3.36) onto the main page at the gtkwave.sourceforge.net website.
 
 -Tony


Thanks Tony.

The gtkwave.zip shows as updated:
Contents/   May/03/12  6:40 PM
Contents/MacOS/gtkwave-bin  May/03/12  6:40 PM

The waveform still appears incorrect.

s6r (#42) shows correctly except for the trailing 9.. in the fraction part, 
#38, #39, #40, #41 display 0 instead of 2 at 2). Seems a problem s6r too or 
ghwdump may be truncating #42 removing the trailing 9..

This is with the same .ghw waveform file I generated yesterday.  I updated the 
save file to fit to your screen size and set the cursor close to the following 
extracted by ghwdump.

 /Applications/gtkwave.app/Contents/Resources/bin/ghwdump -shtv *.ghw  
 ghw_dump
(yesterday, I'm GMT-12)

  ...
  signal s2: integer #34
  signal s3: positive #35
  signal s4: natural #36
  signal s5: anon #37
  signal s2r: real #38
  signal s3r: real #39
  signal s4r: real #40
  signal s5r: real #41
  signal s6r: real #42
  ...
Time is 3000 fs
#1: '1' (3)
#2: '0' (2)
#3: '0' (2)
#4: '0' (2)
#5: '0' (2)
#6: '0' (2)
#7: '0' (2)
#8: '0' (2)
#9: '0' (2)
#10: '0' (2)
#11: '0' (2)
#12: '0' (2)
#13: '0' (2)
#14: '0' (2)
#15: '0' (2)
#16: '1' (3)
#17: '0' (2)
#18: '0' (2)
#19: '0' (2)
#20: '0' (2)
#21: '0' (2)
#22: '0' (2)
#23: '0' (2)
#24: '0' (2)
#25: '0' (2)
#26: '0' (2)
#27: '0' (2)
#28: '0' (2)
#29: '0' (2)
#30: '0' (2)
#31: '0' (2)
#32: '1' (3)
#33: '0' (2)
#34: 2
#35: 2
#36: 2
#37: 2
#38: 2
#39: 2
#40: 2
#41: 2
#42: 8.5615
 ...



real_tb.ghw
Description: Binary data


ghw_dump
Description: Binary data


real_tb.gtkw
Description: Binary data



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Displaying converted Integers to Real fails on amd64-machines with gtkwave = 3.3.19

[David Koontz]

I didn't mean to come across as a floating point purist.  It points to a 
disparity in how ghwdump prints and how gtkwave sprintfs the value for display.

As I understand it the gtkwave user can also do realtobits if they are doing 
gate level modeling. If someone is doing textual comparison they can filter 
precision and crossing over to/from IEEE 754 is their own concern. 

Any idea why I'm not seeing your fix for s2r, s3r, s4r and s5r?  (#38, #39, #40 
and #41)
All they display is zeros, when ghwdump appears to show non-zero values.


On May 5, 2012, at 10:12 AM, byb...@nc.rr.com byb...@nc.rr.com wrote:

 David,
 
 ghwlib uses %g.  I use %.16g for my format.  I have no idea what a user wants 
 so I print full precision.  From a usability point-of-view I can see how this 
 is annoying.
 
 Given how nice power of ten fractions often have no accurate representation 
 in IEEE, that's what you're seeing.
 
 I should probably add an option for users to specify how many significant 
 digits should be. (i.e., the formatting argument)  The fix would be easy and 
 would be localized here:
 
 baseconvert.c:sprintf(os, %.16g, d);
 baseconvert.c:sprintf(rv,%.16g,*d); 
 baseconvert.c:sprintf(os, %.16g, d);
 
 -Tony


 
 
 #include stdio.h
 #include stdlib.h
 
 int main(void)
 {
 double d = 8.5614999;
 double e = 8.5615;
 
 printf(%g\n, d);
 printf(%.16g\n, d);
 
 printf(%g\n, e);
 printf(%.16g\n, e);
 
 return(0);
 }
 
 
 74:/tmp ./t
 8.5615
 8.5614999
 8.5615
 8.5615001
 
 
 
 
  David Koontz diogra...@gmail.com wrote: 
 On May 5, 2012, at 4:43 AM, byb...@nc.rr.com byb...@nc.rr.com wrote:
 
 Fixed in SVN revision 620.  Thanks for reporting this.
 
 I've also just uploaded a fixed OSX gtkwave.zip app bundle (candidate for 
 3.3.36) onto the main page at the gtkwave.sourceforge.net website.
 
 -Tony
 
 
 Thanks Tony.
 
 The gtkwave.zip shows as updated:
 Contents/May/03/12  6:40 PM
 Contents/MacOS/gtkwave-bin   May/03/12  6:40 PM
 
 The waveform still appears incorrect.
 
 s6r (#42) shows correctly except for the trailing 9.. in the fraction 
 part, #38, #39, #40, #41 display 0 instead of 2 at 2). Seems a problem s6r 
 too or ghwdump may be truncating #42 removing the trailing 9..
 
 This is with the same .ghw waveform file I generated yesterday.  I updated 
 the save file to fit to your screen size and set the cursor close to the 
 following extracted by ghwdump.
 
 /Applications/gtkwave.app/Contents/Resources/bin/ghwdump -shtv *.ghw  
 ghw_dump
 (yesterday, I'm GMT-12)
 
  ...
  signal s2: integer #34
  signal s3: positive #35
  signal s4: natural #36
  signal s5: anon #37
  signal s2r: real #38
  signal s3r: real #39
  signal s4r: real #40
  signal s5r: real #41
  signal s6r: real #42
  ...
 Time is 3000 fs
 #1: '1' (3)
 #2: '0' (2)
 #3: '0' (2)
 #4: '0' (2)
 #5: '0' (2)
 #6: '0' (2)
 #7: '0' (2)
 #8: '0' (2)
 #9: '0' (2)
 #10: '0' (2)
 #11: '0' (2)
 #12: '0' (2)
 #13: '0' (2)
 #14: '0' (2)
 #15: '0' (2)
 #16: '1' (3)
 #17: '0' (2)
 #18: '0' (2)
 #19: '0' (2)
 #20: '0' (2)
 #21: '0' (2)
 #22: '0' (2)
 #23: '0' (2)
 #24: '0' (2)
 #25: '0' (2)
 #26: '0' (2)
 #27: '0' (2)
 #28: '0' (2)
 #29: '0' (2)
 #30: '0' (2)
 #31: '0' (2)
 #32: '1' (3)
 #33: '0' (2)
 #34: 2
 #35: 2
 #36: 2
 #37: 2
 #38: 2
 #39: 2
 #40: 2
 #41: 2
 #42: 8.5615
 ...
 
 


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Displaying converted Integers to Real fails on amd64-machines with gtkwave = 3.3.19

[David Koontz]

I get a 0 unchanging in a 3.3.29 gtkwave.app I got from the gtkwave sourceforge 
site using Mac OS X 10.7.3 (Lion, x86_64).

Using ghwdump it appears the reals are being declared to the correct value at 
the proper times. ghwdump gives us an independent view of the contents of the 
ghw waveform file.

/Applications/gtkwave.app/Contents/Resources/bin/ghwdump -shtv *.ghw  ghw_dump

  signal s3r: real #39
  signal s4r: real #40
  signal s5r: real #41
  signal s6r: real #42

(e.g. search for #41 following a line containing event time and specifiying 
simulation time)

 At each event time you can see the value of the signals logged against that 
signal (#42 is your real with the fractional part, it shows up in the time 
events and correctly on the waveform display).  The ones without fractions 
(appearing as integers or naturals in ghwdump output) increment by 1 but the 
displayed waveform shows 0, always.

Because ghw is a binary format I hoped it might be easier to diff 3.3.18 and 
3.3.19 and look for collisions with function names in the ghw code in gtkwave.  
No such luck.

The whole thing looks like it might take some analysis for the non-author, 
starting with understanding the ghw format.  There are maybe a dozen lines 
different and involving ghw between .18 and .19.   Try diffing src/ghw.c 
between the two.

Tony appears to have switched to svn at 3.3.19.  The cvs tree shows the 
differences between 3.3.18 and 3.3.19 by date (see CHANGELOG.TXT). ghw.c  
changes are describes as +8 -2 lines.  It's describe as:

added tree allocation pool when misaligned structs are enabled

It seems it's part of something bigger.

(all this on sourceforge)


On May 4, 2012, at 1:35 PM, Dave Webb wrote:

 In-Reply-To: f5859ca7-cfe0-4d03-b065-0b7018115...@gmail.com
 
 Hi there,
 
 I ran into the same problem as Svenn and I think this might be a
 problem with gtkwave, not with ghdl.
 
 Converting integers to reals seems to work in ghdl but gtkwave does
 not display them properly.
 The real is stuck to its initial value.
 This is very strange because an unconverted real value is displayed
 correctly (see signal s6r in my testbench).
 
 I did several tests and I'm pretty sure that this problems is with
 gtkwave = 3.3.19 only on 64 bit machines.
 gtkwave = 3.3.19 works fine on 32bit machines.
 
 I tested 3.3.xx on two 64 bit machines (system (e) and (c)), with xx =
 xx = 10: OK
 xx = 12: OK
 xx = 18: OK
 xx = 19: NOT OK
 xx = 20: NOT OK
 xx = 21: NOT OK
 xx = 24: NOT OK
 xx = 33: NOT OK
 xx = 35: NOT OK
 
 On a 32 bit machine (system (b))
 10: OK
 18: OK
 19: OK
 34: OK
 35: OK
 
 What I did:
 1) See real_tb.vhd and make.sh
 These are my testfiles you can use to reproduce the bug.
 
 2) My installations
 a) Virtualbox with Debian Wheezy 64 bit
 Linux vm-rca 3.2.0-2-amd64 #1 SMP Sun Apr 15 16:47:38 UTC 2012 x86_64 
 GNU/Linux
 
 ghdl 0.29
 Architecture: amd64
 Source: ghdl (0.29+gcc4.3.4+dfsg-1)
 Version: 0.29+gcc4.3.4+dfsg-1+b2
 
 gtkwave 3.3.35
 Architecture: amd64
 Version: 3.3.35-1
 
 b) Virtualbox with Debian squeeze 32 bit
 Linux rca32 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux
 
 ghdl 0.29
 Architecture: i386
 Source: ghdl (0.29+gcc4.3.4+dfsg-1)
 Version: 0.29+gcc4.3.4+dfsg-1+b1
 
 gtkwave 3.3.10
 Architecture: i386
 Version: 3.3.10-1
 
 c) Virtualbox with Debian squeeze 64 bit
 Linux rca64-test 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012
 x86_64 GNU/Linux
 
 ghdl 0.29
 Architecture: amd64
 Source: ghdl (0.29+gcc4.3.4+dfsg-1)
 Version: 0.29+gcc4.3.4+dfsg-1+b1
 
 gtkwave 3.3.10
 Architecture: amd64
 Version: 3.3.10-1
 
 d) OS X Snow Leopard 64 bit 10.6.8
 gtkwave 3.3.36 (from gtkwave.zip)
 gtkwave 3.3.35 (from homebrew, compiled form updated source)
 
 On system (b), (c) and (e) the problem occurred when switching from
 gtkwave 3.3.18 to 3.3.19
 It was independent of where the ghw file was created (System (a), (b) or (c)).
 Due to limited disk space I was not able to compile gtkwave on System (a).
 
 Any suggestions how to fix the problem?
 
 Kind regards
 
 Dave
 real_tb.vhdmake.shreal_tb.sav___
 Ghdl-discuss mailing list
 Ghdl-discuss@gna.org
 https://mail.gna.org/listinfo/ghdl-discuss




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] message warning

[David Koontz]

On Apr 4, 2012, at 6:06 AM, René Doß wrote:

 I have a wish. More information on warning.
 I get the Information of the library. For me it is important which signal in 
 my code is in trouble. I need a signal name in my code. Can you also print 
 out the higher instance name? I would extremely help.



You'd find that the error messages are actually specified in 
numeric_std_body.vhdl.  numeric_std was originally released as part of the 
1076.2 effort in 1997 and is incorporated in IEEE Std 1076-2008 (see Annex A, 
A.2.4 Standard synthesis packages where the packages can be downloaded from 
http://standards.ieee.org/downloads/1076/1076-2008/  (see 
http://standards.ieee.org/downloads/1076/1076-2008/1076-2008_machine-readable.zip)).

There are also copies released under 1076.2 (see 
http://standards.ieee.org/downloads/1076/1076.2-1996/ for individual VHDL 
files), which appears to be where Tristan procured them.

These are all copyright by the IEEE and distributed conditionally.  They do 
have authority to be modified.  See numeric_std.vhdl from the 2008 distribution 
for example:

--   Note  :  This package may be modified to include additional data
-- :  required by tools, but it must in no way change the
-- :  external interfaces or simulation behavior of the
-- :  description. It is permissible to add comments and/or
-- :  attributes to the package declarations, but not to change
-- :  or delete any original lines of the package declaration.
-- :  The package body may be changed only in accordance with
-- :  the terms of Clause 16 of this standard.

While the numeric_std found in the 1076.2 distribution shows:

-- This package may be modified to include additional data required by tools,
-- but it must in no way change the external interfaces or simulation behavior
-- of the description. It is permissible to add comments and/or attributes to
-- the package declarations, but not to change or delete any original lines of
-- the package declaration. The package body may be changed only in accordance
-- with the terms of 7.1 and 7.2 of this standard.

We might notice that the clause number 16 refers to the IEEE Std 1076-2008, 
wherein 16.8.5.2 Allowable modifications specifies what changes can be made to 
the included IEEE packages.

7.1 and 7.2  reflect IEEE Std 1076.3-1997  and 7.1 gives permission:

The text of messages associated with assertions may differ in the rewritten 
subprogram.

Although there is a requirement that the NO_WARNING assertion mechanism remain 
in effect.  The same restrictions hold true in IEEE Std 1076-2008.

As a practical point the information you are after can be found by using IEEE 
Std 1076-1993 Section 14 Predefined language environment,, 14.1 Predefined 
attributes.  See E'SIMPLE_NAME,  E'INSTANCE_NAME  and E'PATH_NAME.  Named 
entities specified in 5.1 include entity, architecture, configuration, 
procedure, function, package, type, subtype, constant, signal, variable, 
component, label, literal, units, group and file.
Without checking to determine ghdl implements these two predefined attributes 
compliantly you could note there is nothing stoping  the aficionado from making 
changes to numeric_std_body.vhdl. 

The ghdl reference 3.12 IEEE math packages (see 
http://ghdl.free.fr/ghdl/IEEE-math-packages.html)  gives an indication of what 
would be required to replace the numeric_std package body.  Finding the IEEE 
library install directory can be be distribution dependent and can require root 
access in some cases.

Note that downloading the source requires that you have lawful copies of the 
IEEE standards.  The source for some IEEE standard packages including 
numeric_std is distributed with ghdl source.

Essentially the functionality you are after can be implemented in VHDL and is 
within your grasp assuming the attributes are functional and compliant.  Come 
up with something clean and functional and I'd imagine Tristan would be more 
than happy to incorporate message changes into ghdl's version.

There are IIR objects for the attributes in ghdl, they are closely related and 
at least one of them is required for VITAL.  I'd expect they work.  They were 
added in ghdl 0.7 (see http://ghdl.free.fr/NEWS) and were introduced in VHDL-93 
just for the purposes you envision.  

You can find examples using the attributes by googling say for  
INSTANCE_NAME SIMPLE_NAME VHDL .

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Need information and task

[David Koontz]

On Jan 26, 2012, at 1:46 AM, why...@f-cpu.org wrote:

 
 Could somebody make a mirror that is easily accessible ?

Everyone complains about the weather but no one does anything about it.



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Using ghdl together with the Xilinx ISE tool chain

[David Koontz]

See addendum at bottom.

On Jan 8, 2012, at 6:14 PM, David Koontz wrote:

 
 On Jan 6, 2012, at 6:48 PM, David Koontz wrote:
 
 While technically challenging, a rather dry subject.
 
 Getting to the actual error:
 
 On Jan 6, 2012, at 6:48 PM, David Koontz wrote:
 
 
 Second, 
 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 
 Is going to require some finessing to analyze and elaborate.  The model 
 (tbx_test) isn't complete without it. 
 grep -i mux work-obj93.cf returns nothing.
 (This is with the mcode version of GHDL-0.29 on Mac OS X).
 
 
 
 I'd suspect one of those changes in 08 or 09 are responsible:
 
 david_koontz@Macbook: ghdl -r tbx_test  --stop-time=500us 
 --wave=simu_tb_test_timesim.ghw 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
 
 (The component instance is unbound regardless of applying an sdf file.)  I'd 
 suspect It would have to be debugged on a Linux machine.
 
 
 
 Linux does the same thing
 =
 
 The component declaration in simprims/simprim_Vcomponents.vhd doesn't match 
 that found in the entity declaration for 
 simprims/primitive/other/X_BUFGMUX.vhd.
 
 A check in a Linux version of ghdl (GHDL 0.29 ) shows:
 
 david-koontz-VirtualBox:/mnt/share/9597% ghdl -e tbx_test
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
 david-koontz-VirtualBox:/mnt/share/9597% ghdl -r --no-vital-checks 
 --warn-no-vital-generic tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
 --wave=simu_tb_test_timesim.ghw
 ./tbx_test:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o
 /usr/lib/ghdl/bin/ghdl: compilation error
 
 (tpd_i0_o happens to be the first vital timing value annotated, in an X_BUF 
 If I recall correctly).
 
 We get the same answer under Linux.  The story here is that ghdl is doing the 
 right thing under ISE 13.2 so far.   Generating a local component declaration 
 resulted in different errors.  A solution might be to find an older version 
 of ISE, preferably one not requiring installation  (a backup image).  
 Handcrafting a working BUFGMUX requires more knowledge of VITAL than I'm 
 willing to acquire in the short term.  (My first choice would be to use an 
 FPGA's static timing analysis tools, the number of different delay values, 
 etc., involved is limited although you could contemplate the issue of clock 
 domain crossing).
 
 Getting the X_BUFGMUX Cell to be bound
 =
 
 So I found I had a copy of ISE 9.1 which I extracted X_BUFGMUX.vhd, from 
 renamed the entityt to X_BUFGMUX_X, created a component declaration for in 
 the architecture declarative region, renamed the CELLTYPE in the SDF file to 
 match, and:
 
 ghdl -a X_BUFGMUX.vhd
 X_BUFGMUX.vhd:37:5:warning: generic loc is not a VITAL generic
 X_BUFGMUX.vhd:42:7:warning: 'gsr' is not a port name (in VITAL generic name)
 
 ghdl -a test_timesim.vhd
 ghdl -a tb_test_timesim.vhd
 (Linux would have a ghdl -e tbx_test here)
 ghdl -r --no-vital-checks --warn-no-vital-generic tbx_test 
 --sdf=uut=test_timesim.sdf --stop-time=500us --wave=simu_tb_test_timesim.ghw
 ghdl:error: vital: unhandled generic type for generic 
 tsetup_s_i0_posedge_negedge
 
 
 I used just the X_BUFGMUX.vhd file extracted from the single vhdl file 
 containing all the simprim primitives because in 9.1 there is an implication 
 of using synopsys arithmetic in some of the later primitives (e.g. DSP48) 
 which I wanted to avoid.  There is not distinction between other and mti in 
 9.1 implying the IEEE arithmetic libraries weren't in effect yet.
 
 So, because there is a Vital timing check for setup and hold from S to i0, 
 positive edge S to negative edge  in this version of X_BUFGMUX.vhd and the 
 error message is from the ghdl run time library (grt), 
 grt-vital_annotate.adb, we can assumed ghdl is reporting that it isn't doing  
 a setup and hold time check  (and this is the first one of two setup and two 
 hold checks in this X_BUFGMUX.vhd, unhappy about something).
 
 
 As an aside the only thing this particular timing check can test is 
 effectively cycle time for the faster of the two clocks on this clock buffer 
 (i0 or i1) based on the Select (S) delay from a synchronous event driving S.  
 For a simulation just checking back annotation for an XOR gate, who cares?
 
 The question is whether you can do any timing checks for setup and hold time?
 
 SDF File Syntax
 =
 
 Looking at the SDF file for X_BUFGMUX:
 
   (CELL (CELLTYPE X_BUFGMUX_X)
 (INSTANCE clk_BUFGP_BUFG)
   (DELAY
 (ABSOLUTE
   (IOPATH I0 O ( 0 ))
   (IOPATH I1 O ( 0 ))
 )
   )
   (TIMINGCHECK
 (SETUPHOLD (posedge S) (negedge I0) (480:600:600)(0))
   )
   )
 There are two timing rvalues

Re: [Ghdl-discuss] postfitting timing simulation with XIlinx

[David Koontz]

On Jan 14, 2012, at 11:10 PM, tging...@free.fr wrote:

 Part of the understanding required to implement the semantic
 restrictions therein would be understanding what is meant by
 discrete range and whether di'length-1 is valid as a bound of a
 discrete range.
 
 No, because of:
 
 --  LRM 3.2.1.1  Index constraints and discrete ranges
 --  For a discrete range used in a constrained array
 --  definition and defined by a range, an implicit
 --  conversion to the predefined type INTEGER is assumed
 --  if each bound is either a numeric literal or an
 --  attribute, and the type of both bounds (prior to the
 --  implicit conversion) is the type universal_integer.
 
 Tristan. 

You're, right.

3.1.2 Integer types

An integer type definition defines an integer type whose set of values includes 
those of the specified range.

 integer_type_definition ::=  range_constraint

An integer type definition defines both a type and a subtype of that type. The 
type is an anonymous type, the range of which is selected by the 
implementation; this range must be such that it wholly contains the range given 
in the integer type definition. The subtype is a named subtype of this 
anonymous base type, where the name of the subtype is that given by the 
corresponding type declaration and the range of the subtype is the given range.

Each bound of a range constraint that is used in an integer type definition 
must be a locally static expression of some integer type, but the two bounds 
need not have the same integer type. (Negative bounds are allowed.)

Integer literals are the literals of an anonymous predefined type that is 
called universal_integer in this standard. Other integer types have no 
literals. However, for each integer type there exists an implicit conversion 
that converts a value of type universal_integer into the corresponding value 
(if any) of the integer type (see7.3.5 ).

The position number of an integer value is the corresponding value of the type 
universal_integer.


But the statement offering a qualified enable of conversion found in 3.2.1.1  
isn't a prohibition for doing so otherwise.  That's found here:

7.3.5  Type conversion
...
In certain cases, an implicit type conversion will be performed. An implicit 
conversion of an operand of type universal_integer to another integer type, or 
of an operand of type universal_real to another floating point type, can only 
be applied if the operand is either a numeric literal or an attribute, or if 
the operand is an expression consisting of the division of a value of a 
physical type by a value of the same type; such an operand is called a 
convertible universal operand. An implicit conversion of a convertible 
universal operand is applied if and only if the innermost complete context 
determines a unique (numeric) target type for the implicit conversion, and 
there is no legal interpretation of this context without this conversion. 

The language is also in VHDL-87.   It's tempting to want to make it work 
because as in this case di is globally static.

The only advantage to the limitation I can see is the ability to unroll loops, 
and even then there are ways around it including the known exceptions.  Declare 
a range constraint as a type in a block declarative region, the alias as the 
work around showed...   Any case where the loop constraints aren't locally 
static.

I wrote a test case using one of the RAM16BWER procedures offending procedures 
and it simulates just fine.  Your warning isn't being interrupted as an error 
and isn't causing a memory leak.


 red@linux-nrd1:~/projekt/mips/LM_CPU/ise/netgen/map make run
 ghdl -r tb_lm_cpu --sdf=./=lm_cpu_map.sdf --wave=tbench.ghw --stop-time=500us
 ./tb_lm_cpu:internal error: cannot allocate stack: memory exhausted
 ghdl: compilation error
 make: *** [run] Error 1
 
 That runs out of stack space. I have use the stack size option 200MB but 
 this crashed anywhere.
 I feel it is a short step into the goal.



What's causing the memory leak?  I ran the test case (admittedly with only one 
offending for loop case) for 8 seconds of simulation time and collected over a 
half Gigabyte of dump file without the execution process memory size changing 
after the simulation started for six signals (40 ns cycle time). All this in 
mcode code converter version running on a Mac.  The memory leak isn't to do 
with loop constraints (directly).

There's uncertainty involved not having the original model to test with.

 ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic 
 --ieee=synopsys -fexplicit tb_lm_cpu
 ../../../src/vital2000/timing_b.vhdl:196:15:warning: procedure vitalerror 
 is never referenced
 ../../../src/vital2000/timing_b.vhdl:217:15:warning: procedure vitalerror 
 is never referenced
 ../../../src/vital2000/prmtvs_b.vhdl:1041:15:warning: function toedge is 
 never referenced
 

Re: [Ghdl-discuss] teaching with GHDL -- VHPI an VHDL-2008

[David Koontz]

On Jan 14, 2012, at 11:09 PM, Walter F.J. Mueller wrote:

 I put it a little wider:
 
 - when ghdl wants to survive on the long run it has to implement
   also the major vhdl-2008 language features in the future.
 - by the time vhdl-2008 is supported by synthesis tools one wants
   to use some of them, and it be sad if the state of ghdl would
   prevent that.
 - vhpi and thus C code interfacing is now formally part of vhdl-2008.

You realize we're working on P1076-2013 right now.

The majority of HDL use in the world is still probably VHDL.   There's a fairly 
small number of users clamoring for compliance, involved in verification and 
system simulation.  

Historically new version standards compliance was a marketing qualifier.  That 
hasn't really been the case.  Xilinx for instance does using configuration 
statements properly - you can't overload generic yet identically interfaced 
entities with specific ones by configuration.  It means you can't instance 
hierarchy containing elements differing by contents but not interface.  An 
example would be a standard ROM, with different contents in several 
instantiations.   (And yes you could partially load them, but that isn't the 
point, it's a pain to load them in your simulator and requires a gate level 
representation (primsim or unisim).

If you can't get the guys responsible for some large part of the VHDL use to be 
compliant with VHDL-93, what good is yet another version?

I'm aware of one vendor claiming to be VHDL-2008 compliant, but I'd be willing 
to bet someone could write test cases that would disabuse the notion.  There's 
also a couple of things in 2008 that are guaranteed to kill performance if 
used.  

The point of all this is that the standard isn't driving the tools, it's 
feature usage, and the two aren't as strongly coupled as they might have been 
in the past, particularly in the view of those interested in creating a 
System-VHDL.  The market for that is already occupied by System-Verilog and 
System-C and one of the two of those could co-exist in a simulation engine with 
VHDL.  






___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] teaching with GHDL

[David Koontz]

On Jan 13, 2012, at 1:03 AM, Dr. Douglas Lyon wrote:

 The compiler should probably be ported to something like Java,
 then VHDL could be a write once, run anywhere type language, and
 that would be a hoot.

How about porting it to hardware?  Should be small enough to run on a smallish 
FPGA, but you'd need I/O protocols for storage/input source, and virtual memory.

Mind you it would run slow as a simulation.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] GHDL Mailing list

[David Koontz]

On Jan 13, 2012, at 2:05 AM, Ben Gasch wrote:

 Bonjour,
 
 Pourriez vous me retirer de la mailing list. Je ne souhaite plus recevoir les 
 discussions.
 
 Merci d'avance.
 
 Benoit Gasch
 ___
 Ghdl-discuss mailing list
 Ghdl-discuss@gna.org
 https://mail.gna.org/listinfo/ghdl-discuss

https://mail.gna.org/listinfo/ghdl-discuss/

Ghdl-discuss Subscribers

To unsubscribe from Ghdl-discuss, get a password reminder, or change your 
subscription options enter your subscription email address:

  [unsubscribe button]
If you leave the field blank, you will be prompted for your email address   


Ghdl-discuss Abonnés

Pour vous désabonner d'ghdl-discuss, recevoir un rappel de mot de passe ou 
modifier vos options d'abonnement, entrez votre adresse courriel d'abonnement:

   [bouton désabonnement]
Si vous laissez le champ vide, vous serez invité à fournir votre adresse e-mail

(Blame it on Google Translate)

___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Building GHDL on top of a newer GCC - OS X

[David Koontz]

On Jan 13, 2012, at 2:46 AM, Dave Webb wrote:

 Hi all,
 
 On Thu, Jan 12, 2012 at 2:01 PM, David Koontz diogra...@gmail.com wrote:
 You're github ghdl looks like it may not be up to date:
 ../../untar/gcc-4.6.0/gcc/vhdl/ortho-lang.c:766: parse error: GTY must be 
 specified before identifier
 I already did some patching for these syntax changes in my github files.
 https://github.com/davewebb8211/ghdl/
 in the 'nick' branch.
 https://github.com/davewebb8211/ghdl/commit/2646d165b2b5c01161b0e498c8b33f9ebcd54248
 
 Undefined symbols for architecture x86_64:
  _iconv_open, referenced from:
 
 I'm using homebrew and linking was not a problem.
 It was enough to mention -liconv and so it linked against the one in /usr/lib
 https://github.com/davewebb8211/ghdl/commit/2646d165b2b5c01161b0e498c8b33f9ebcd54248
 
 Once I figure out to get the right one specified (and there'll be the 
 matching includes) I just may have linked cc1 (ghdl1) (fingers crossed).
 Have you got warning while compiling (pointer stuff?) and did you
 apply other patches?
 
/opt/gcc-4.6.0-x86_64/bin/gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-Wold-style-definition -Wc++-compat  -Wno-error -DHAVE_CONFIG_H -I. -I. 
-I../../untar/gcc-4.6.0/gcc -I../../untar/gcc-4.6.0/gcc/. 
-I../../untar/gcc-4.6.0/gcc/../include -I./../intl 
-I../../untar/gcc-4.6.0/gcc/../libcpp/include -I/opt/local/include 
-I/opt/local/include  -I../../untar/gcc-4.6.0/gcc/../libdecnumber 
-I../../untar/gcc-4.6.0/gcc/../libdecnumber/dpd -I../libdecnumber
../../untar/gcc-4.6.0/gcc/expmed.c -o expmed.o
../../untar/gcc-4.6.0/gcc/expmed.c: In function ‘init_expmed’:
../../untar/gcc-4.6.0/gcc/expmed.c:134:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:141:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:145:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:149:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:153:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:157:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:164:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:180:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:184:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:188:3: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:231:8: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:246:8: warning: array subscript is above 
array bounds [-Warray-bounds]
../../untar/gcc-4.6.0/gcc/expmed.c:247:8: warning: array subscript is above 
array bounds [-Warray-bounds]


And :


rm -rf libbackend.a
ar rc libbackend.a insn-attrtab.o insn-automata.o insn-emit.o insn-extract.o 
insn-modes.o insn-opinit.o insn-output.o insn-peep.o insn-preds.o insn-recog.o 
insn-enums.o ggc-page.o alias.o alloc-pool.o auto-inc-dec.o bb-reorder.o 
bitmap.o bt-load.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o 
cfgcleanup.o cfgexpand.o cfghooks.o cfglayout.o cfgloop.o cfgloopanal.o 
cfgloopmanip.o cfgrtl.o combine.o combine-stack-adj.o compare-elim.o convert.o 
coverage.o cse.o cselib.o dbxout.o dbgcnt.o dce.o ddg.o debug.o df-core.o 
df-problems.o df-scan.o dfp.o diagnostic.o dojump.o dominance.o domwalk.o 
double-int.o dse.o dwarf2asm.o dwarf2out.o ebitmap.o emit-rtl.o et-forest.o 
except.o explow.o expmed.o expr.o final.o fixed-value.o fold-const.o function.o 
fwprop.o gcse.o ggc-common.o gimple.o gimple-iterator.o gimple-fold.o 
gimple-low.o gimple-pretty-print.o gimplify.o godump.o graph.o graphds.o 
graphite.o graphite-blocking.o graphite-clast-to-gimple.o graphite-cloog-util.o 
graphite-dependences.o graphite-flattening.o graphite-interchange.o 
graphite-poly.o graphite-ppl.o graphite-scop-detection.o 
graphite-sese-to-poly.o gtype-desc.o haifa-sched.o hooks.o hwint.o ifcvt.o 
implicit-zee.o init-regs.o input.o integrate.o intl.o ira.o ira-build.o 
ira-costs.o ira-conflicts.o ira-color.o ira-emit.o ira-lives.o jump.o 
langhooks.o lcm.o lists.o loop-doloop.o loop-init.o loop-invariant.o loop-iv.o 
loop-unroll.o loop-unswitch.o lower-subreg.o lto-cgraph.o lto-streamer-in.o 
lto-streamer-out.o lto-section-in.o lto-section-out.o lto-symtab.o lto-opts.o 
lto-streamer.o lto-compress.o mcf.o mode-switching.o modulo-sched.o omega.o 
omp-low.o optabs.o options.o opts-common.o opts-global.o opts.o params.o 
passes.o plugin.o pointer-set.o postreload-gcse.o postreload.o

Re: [Ghdl-discuss] Building GHDL on top of a newer GCC

[David Koontz]

On Jan 11, 2012, at 5:20 AM, Dave Webb wrote:

 Hi all,
 
 https://github.com/nickg/ghdl/tree/nick
 I just forked that
 https://github.com/davewebb8211/ghdl
 and pushed my changes. At least it compiles with gcc-4.6.0.
 
 As mentioned before, it compiles but now I'm stuck at make install.all
 in ./translate/ghdldrv. I get ghdl1-gcc:*command-line*: cannot find
 std library. This is a small improvement to my last post. I haven't
 understand all the gimple tree stuff.
 

Not exactly crew but I used to do a lot of gcc stuff a few years ago.  I'm also 
working on a Mac, so I figured in share a little more of the cautionaries you 
can run into.  This under OS X 10.7.2, which isn't particularly bad.  
Unfortunately I have 7 gcc tool sets on the the thing (plus two in a VM running 
lubuntu) and it requires setting paths for libgmp,mpfr, etc, because there's 32 
bit set of tools from Adacore I use to build the machine code version sitting 
in /usr/local until I can figure out what to do about the whinging over 
incompatible assembly language and inline code files.

Anyway I uncompressed the distributions involved in building gcc with vhdl 
(only) in a parallel directory to build and gcc-4.6.0 and run this script:

david_koontz@Macbook: more ../archives/script
#!/bin/csh -v
cp -r gcc-4.6.0 ..
cp -r gmp-5.0.2 ../gcc-4.6.0/gmp
cp -r mpc-0.9  ../gcc-4.6.0/mpc
cp -r mpfr-3.1.0 ../gcc-4.6.0/mpfr
cp -r ghdl-0.29/vhdl ../gcc-4.6.0/gcc
mkdir ../build
cd ../build

setenv CC /opt/local/bin/gcc-mp-4.6
setenv GCC /opt/local/bin/gcc-mp-4.6  # actually 4.6.2 from Macports
setenv GNAT /opt/gcc-4.6.0-x86_64/bin

# configure with disabled bootstrap
#just vhdl
../gcc-4.6.0/configure --with-gmp=/opt/local --with-mpfr=/opt/local 
--with-gmp=/opt/local --enable-languages=vhdl --disable-bootstrap 
--target=x86_64-apple-darwin --build=x86_64-apple-darwin 
--host=x86_64-apple-darwin
make -j12
 --
And interestingly enough  according to Lluis Batlle i Rossell 
(http://www.mail-archive.com/ghdl-discuss@gna.org/msg01187.html) gmake can give 
you:

 make[3]: *** No rule to make target `../gcc/gtype-vhdl.h', needed by 
 `ortho-lang.o'.  Stop.

When using the -jN flag.  I can attest to that.  Ya could wonder if someone 
wasn't blocking on sucessive dependencies or something.

(http://rpmfind.net/linux/RPM/epel/6/i386/debug/ghdl-debuginfo-0.29-0.138svn.1.el6.i686.html)

And look, it was doing multilib stuff right before the error:

cho #define BUILDING_GCC_MINOR `echo 4.6.0 | sed -e 
's/^[0-9]*\.\([0-9]*\).*$/\1/'`  bversion.h
echo 'END_OF_BASE_TREE_CODES'  tmp-all-tree.def
echo '#include c-family/c-common.def'  tmp-all-tree.def
echo timestamp  s-gtyp-input
ltf=; for f in $ltf; do \
  echo #include \$f\; \
done | sed 's|../../gcc-4.6.0/gcc/||'  tmp-all-tree.def
echo #define BUILDING_GCC_PATCHLEVEL `echo 4.6.0 | sed -e 
's/^[0-9]*\.[0-9]*\.\([0-9]*\)$/\1/'`  bversion.h
if test yes = yes \
   || test -n ; then \
  /bin/sh ../../gcc-4.6.0/gcc/genmultilib \
m32 \
i386 \
 \
 \
 \
 \
 \
yes \
 tmp-mlib.h; \
else \
  /bin/sh ../../gcc-4.6.0/gcc/genmultilib '' '' '' '' '' '' '' no \
 tmp-mlib.h; \
fi
/bin/sh ../../gcc-4.6.0/gcc/../move-if-change tmp-all-tree.def all-tree.def
echo #define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 + 
BUILDING_GCC_MINOR)  bversion.h
lsf=../../gcc-4.6.0/gcc/vhdl/lang-specs.h; for f in $lsf; do \
echo #include \$f\; \
done | sed 's|../../gcc-4.6.0/gcc/||'  tmp-specs.h
/bin/sh ../../gcc-4.6.0/gcc/../move-if-change tmp-specs.h specs.h
echo timestamp  s-bversion
echo timestamp  s-alltree
echo /opt/local/bin/gcc-mp-4.6   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -L/opt/local/lib  
checksum-options.tmp \
 ../../gcc-4.6.0/gcc/../move-if-change checksum-options.tmp 
checksum-options
echo timestamp  s-specs
awk -f ../../gcc-4.6.0/gcc/config/i386/i386-builtin-types.awk 
../../gcc-4.6.0/gcc/config/i386/i386-builtin-types.def  tmp-bt.inc
make[2]: *** No rule to make target `../gcc/gtype-vhdl.h', needed by 
`ortho-lang.o'.  Stop.
make[2]: *** Waiting for unfinished jobs
/bin/sh ../../gcc-4.6.0/gcc/../move-if-change tmp-bt.inc i386-builtin-types.inc
echo timestamp  s-i386-bt
/bin/sh ../../gcc-4.6.0/gcc/../move-if-change tmp-mlib.h multilib.h
echo timestamp  s-mlib
/bin/sh ../../gcc-4.6.0/gcc/../move-if-change tmp-optionlist optionlist
echo timestamp  s-options
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2

 --

Any way, even for not having current club house membership for a gcc guy, I'll 
see how far it goes.  There's a redhat rpm that adds this as part of a debug 
package I think.

Setting it to -j1 continues 

Re: [Ghdl-discuss] Building GHDL on top of a newer GCC

[David Koontz]

On Jan 11, 2012, at 12:16 AM, Martin Strubel wrote:

 I've run some of the code through Doxygen, see Doxyfile at
 
 http://section5.ch/files/ghdl.Doxyfile.gz
 
 Just copy to ghdl source tree, gunzip, rename to Doxyfile, run doxygen.
 There's some abuse going on by mapping .adb files to VHDL code, so far
 it does not seem to make doxygen choke, but I don't know if it's fully
 parsed, either.
 
 Probably some of the options can be tweaked to produce better results. I
 just used it to quickly get a cross reference.
 
 So the next job could be to do a git based fork and start the
 documentation project. Someone (with more GHDL experience) willing to
 take the hat or the seashell?

I tried it  out, even modifying your ghdl.Doxyfile a bit (e.g. adding .ads 
files as Vhdl types) the results weren't good enough for someone to learn to 
navigate throught  ghdl source code.  

You can do better with the source code and Appendix B of the Gnat User's Guide. 
 Having gotten part way in by hand previously  I couldn't trace my way through 
the produced html even with a road map.  The issue being the vhdl parser for it 
isn't compliant enough.  Try to trace your way from ada_main.  In the specific 
case it looked like it had trouble with procedure declarations found in side a 
function declarative region.  VHDL dannae have such  structures (commonly, it's 
defined in VHDL-2008, rarer than hen's teeth and the vhdl parser for doxygen is 
obviously not compliant).  A quick look at the vhdl scanner and code generator 
shows VHDL accounts for 28,000+ lines of code, saying deriving an acceptable 
Ada parser from it might be be an undertaking.

Does anyone have any experience with Adabrowse?


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Using ghdl together with the Xilinx ISE tool chain -- sdf parser and usage of rtriple

[David Koontz]

On Jan 8, 2012, at 6:49 AM, Walter F.J. Mueller wrote:

 From all that I conclude that the sdf parser in ghdl seems to have
 some problems with the proper treatment of RNUMBER and rtriple and
 seems to require rtriple's even though the SDF spec clearly does not
 require that.

I haven't generated a flow chart on what ghdl does but I believe you're on to 
something here, from the analysis of the 9597 bug I just did.  It turns out 
that the usage (which rvalue) has to be determined from context in any event.  

I'd stop short of claiming that the behavior exhibited isn't 'proper 
treatement'.  It's just not the marketplace norm.  (And SDF 3.0 could modify 
that view).

The rvalue to VitalDelayType* mapping is only one sided in it's view of dealing 
with the different number of rvalues.  It can be made to take both directions 
into consideration instead of just SDF side (and it's consumption side driven 
anyway).

Thanks for the new bug report.  



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Using ghdl together with the Xilinx ISE tool chain

[David Koontz]

On Jan 6, 2012, at 6:48 PM, David Koontz wrote:
While technically challenging, a rather dry subject.

Getting to the actual error:

On Jan 6, 2012, at 6:48 PM, David Koontz wrote:

 
 Second, 
 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 
 Is going to require some finessing to analyze and elaborate.  The model 
 (tbx_test) isn't complete without it. 
 grep -i mux work-obj93.cf returns nothing.
 (This is with the mcode version of GHDL-0.29 on Mac OS X).
 

 
 I'd suspect one of those changes in 08 or 09 are responsible:
 
 david_koontz@Macbook: ghdl -r tbx_test  --stop-time=500us 
 --wave=simu_tb_test_timesim.ghw 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
 
 (The component instance is unbound regardless of applying an sdf file.)  I'd 
 suspect It would have to be debugged on a Linux machine.
 


Linux does the same thing
=

The component declaration in simprims/simprim_Vcomponents.vhd doesn't match 
that found in the entity declaration for simprims/primitive/other/X_BUFGMUX.vhd.

A check in a Linux version of ghdl (GHDL 0.29 ) shows:

david-koontz-VirtualBox:/mnt/share/9597% ghdl -e tbx_test
test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not bound
test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
david-koontz-VirtualBox:/mnt/share/9597% ghdl -r --no-vital-checks 
--warn-no-vital-generic tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu_tb_test_timesim.ghw
./tbx_test:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o
/usr/lib/ghdl/bin/ghdl: compilation error

(tpd_i0_o happens to be the first vital timing value annotated, in an X_BUF If 
I recall correctly).

We get the same answer under Linux.  The story here is that ghdl is doing the 
right thing under ISE 13.2 so far.   Generating a local component declaration 
resulted in different errors.  A solution might be to find an older version of 
ISE, preferably one not requiring installation  (a backup image).  Handcrafting 
a working BUFGMUX requires more knowledge of VITAL than I'm willing to acquire 
in the short term.  (My first choice would be to use an FPGA's static timing 
analysis tools, the number of different delay values, etc., involved is limited 
although you could contemplate the issue of clock domain crossing).

Getting the X_BUFGMUX Cell to be bound
=

So I found I had a copy of ISE 9.1 which I extracted X_BUFGMUX.vhd, from 
renamed the entityt to X_BUFGMUX_X, created a component declaration for in the 
architecture declarative region, renamed the CELLTYPE in the SDF file to match, 
and:

ghdl -a X_BUFGMUX.vhd
X_BUFGMUX.vhd:37:5:warning: generic loc is not a VITAL generic
X_BUFGMUX.vhd:42:7:warning: 'gsr' is not a port name (in VITAL generic name)

ghdl -a test_timesim.vhd
ghdl -a tb_test_timesim.vhd
(Linux would have a ghdl -e tbx_test here)
ghdl -r --no-vital-checks --warn-no-vital-generic tbx_test 
--sdf=uut=test_timesim.sdf --stop-time=500us --wave=simu_tb_test_timesim.ghw
ghdl:error: vital: unhandled generic type for generic 
tsetup_s_i0_posedge_negedge


I used just the X_BUFGMUX.vhd file extracted from the single vhdl file 
containing all the simprim primitives because in 9.1 there is an implication of 
using synopsys arithmetic in some of the later primitives (e.g. DSP48) which I 
wanted to avoid.  There is not distinction between other and mti in 9.1 
implying the IEEE arithmetic libraries weren't in effect yet.

So, because there is a Vital timing check for setup and hold from S to i0, 
positive edge S to negative edge  in this version of X_BUFGMUX.vhd and the 
error message is from the ghdl run time library (grt), grt-vital_annotate.adb, 
we can assumed ghdl is reporting that it isn't doing  a setup and hold time 
check  (and this is the first one of two setup and two hold checks in this 
X_BUFGMUX.vhd, unhappy about something).


As an aside the only thing this particular timing check can test is effectively 
cycle time for the faster of the two clocks on this clock buffer (i0 or i1) 
based on the Select (S) delay from a synchronous event driving S.  For a 
simulation just checking back annotation for an XOR gate, who cares?

The question is whether you can do any timing checks for setup and hold time?

SDF File Syntax
=

Looking at the SDF file for X_BUFGMUX:

  (CELL (CELLTYPE X_BUFGMUX_X)
(INSTANCE clk_BUFGP_BUFG)
  (DELAY
(ABSOLUTE
  (IOPATH I0 O ( 0 ))
  (IOPATH I1 O ( 0 ))
)
  )
  (TIMINGCHECK
(SETUPHOLD (posedge S) (negedge I0) (480:600:600)(0))
  )
  )
There are two timing rvalues passed (480:600:600) and (0)  (in pico seconds, 
TIMESCALE from the SDF Header) the first three case times for setup time and 
the second 0 hold time.  (Keeping in mind I don't have

Re: [Ghdl-discuss] Building GHDL on top of a newer GCC

[David Koontz]

On Jan 8, 2012, at 7:03 AM, Wesley J. Landaker wrote:

 Hey Tristan  other GHDL folks,
 
 Has anyone made any progress getting GHDL ported up to a build on and/or 
 with a newer GCC?
 
 I'm working on updating the GHDL Debian package. Currently it is built on 
 gcc-core-4.3.4 as a base, with gnat-4.4 as the compiler.
 
 This no longer builds in the current Debian environment. I would like to use 
 gnat-4.6, and a newer gcc-core that doesn't have issues with a multilib 
 environment (and has other improvements).
 
 The GHDL Ubuntu packages contain a patch which intrusively modifies gcc-
 core-4.3.4 to make it work somewhat, but this isn't a sustainable solution 
 and doesn't completely fix the problems.
 
 Usually I can get through a couple obstacles, but my current attempts are 
 crashing and burning, and I have less time to work on this than I used to. 
 Has anyone else made any effort to make this work? Any full or partial 
 successes?

I'm going to try this on for shock value, then show a light at the end of the 
tunnel.

First, no one is currently actively developing GHDL.  There has been a dearth 
of volunteers.  Tristan is off working hard for living doing Ada coding for 
what's probably flight critical applications in aerospace.  I should be working 
for a living, too.  Add to that I can't actually upload a release image to 
ghdl.free.fr from outside the free.fr domain, and only critical fixes are going 
to get released, making demands on Tristan's time (or rehosting or forking 
GHDL).

Gcc release cycles have been too frequent for one person to keep up with part 
time (as you can attest).  The implication is that GHDL can't keep up without 
more bodies or code contributions flowing back.  Today there is one part time 
person and people praying for bug fixes.

Currently the lifetime of the gcc front end version of GHDL is bound by the 
ability to compile gcc-4.3.x or otherwise newer version.  

Now for the good news.  I recently came across someone doing a VHDL analyzer 
and simulator inspired by GHDL, written in C.  There is one very interesting 
characteristic although the code is being organically grown (incrementally 
implemented, meaning potentially doing things over as you add complexity).  It 
uses the LLVM code generator (back end) which is separable from the front end, 
uncoupling some of the forced synchronization like you're noting with trying to 
go beyond gcc-4.3.4 and gnat 4.4. 

In the LLVM 3.1 release notes there's mention of a gcc-4.6.1 based front end 
that implements Ada fully.  This new tool adopts LLVM's bitcode library format 
preserving the ability I think to do Link Time Optimization (which an HDL 
simulator can benefit from) and foreign interfaces.

I'd suggest GHDL takes a similar path and uses the LLVM back end in the future, 
in effect leapfrogging to become up to date. This provides a promise of the 
ability to do parallel thread execution at some point, too.

In lieu of crafting the future there's always an mcode version for Linux and 
there's also the issue of VHDL standard compliance, where GHDL isn't fully 
VHDL-93 compliant.

As far as your immediate problem other than Thomas Sailer at the Fedora Project 
 with the multilib stuff, no.  His patches ought to be evaluate fro inclusion 
in ghdl. On the surface gnat-4.6 seems separable from multilibs.

http://download.fedora.redhat.com/pub/fedora/linux/releases/16/Everything/source/SRPMS/ghdl-0.29-2.143svn.4.fc16.src.rpm
 (43+ MB)  See the ghdl.spec file.











___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Using ghdl together with the Xilinx ISE tool chain

[David Koontz]

On Jan 6, 2012, at 6:48 PM, David Koontz wrote:

While technically challenging, a rather dry subject.

Getting to the actual error:

On Jan 6, 2012, at 6:48 PM, David Koontz wrote:

 
 Second, 
 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 
 Is going to require some finessing to analyze and elaborate.  The model 
 (tbx_test) isn't complete without it. 
 grep -i mux work-obj93.cf returns nothing.
 (This is with the mcode version of GHDL-0.29 on Mac OS X).
 

 
 I'd suspect one of those changes in 08 or 09 are responsible:
 
 david_koontz@Macbook: ghdl -r tbx_test  --stop-time=500us 
 --wave=simu_tb_test_timesim.ghw 
 test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not 
 bound
 test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
 
 (The component instance is unbound regardless of applying an sdf file.)  I'd 
 suspect It would have to be debugged on a Linux machine.
 


Linux does the same thing
=

The component declaration in simprims/simprim_Vcomponents.vhd doesn't match 
that found in the entity declaration for simprims/primitive/other/X_BUFGMUX.vhd.

A check in a Linux version of ghdl (GHDL 0.29 ) shows:

david-koontz-VirtualBox:/mnt/share/9597% ghdl -e tbx_test
test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not bound
test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
david-koontz-VirtualBox:/mnt/share/9597% ghdl -r --no-vital-checks 
--warn-no-vital-generic tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu_tb_test_timesim.ghw
./tbx_test:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o
/usr/lib/ghdl/bin/ghdl: compilation error

(tpd_i0_o happens to be the first vital timing value annotated, in an X_BUF If 
I recall correctly).

We get the same answer under Linux.  The story here is that ghdl is doing the 
right thing under ISE 13.2 so far.   Generating a local component declaration 
resulted in different errors.  A solution might be to find an older version of 
ISE, preferably one not requiring installation  (a backup image).  Handcrafting 
a working BUFGMUX requires more knowledge of VITAL than I'm willing to acquire 
in the short term.  (My first choice would be to use an FPGA's static timing 
analysis tools, the number of different delay values, etc., involved is limited 
although you could contemplate the issue of clock domain crossing).

Getting the X_BUFGMUX Cell to be bound
=

So I found I had a copy of ISE 9.1 which I extracted X_BUFGMUX.vhd, from 
renamed the entityt to X_BUFGMUX_X, created a component declaration for in the 
architecture declarative region, renamed the CELLTYPE in the SDF file to match, 
and:

ghdl -a X_BUFGMUX.vhd
X_BUFGMUX.vhd:37:5:warning: generic loc is not a VITAL generic
X_BUFGMUX.vhd:42:7:warning: 'gsr' is not a port name (in VITAL generic name)

ghdl -a test_timesim.vhd
ghdl -a tb_test_timesim.vhd
(Linux would have a ghdl -e tbx_test here)
ghdl -r --no-vital-checks --warn-no-vital-generic tbx_test 
--sdf=uut=test_timesim.sdf --stop-time=500us --wave=simu_tb_test_timesim.ghw
ghdl:error: vital: unhandled generic type for generic 
tsetup_s_i0_posedge_negedge


I used just the X_BUFGMUX.vhd file extracted from the single vhdl file 
containing all the simprim primitives because in 9.1 there is an implication of 
using synopsys arithmetic in some of the later primitives (e.g. DSP48) which I 
wanted to avoid.  There is not distinction between other and mti in 9.1 
implying the IEEE arithmetic libraries weren't in effect yet.

So, because there is a Vital timing check for setup and hold from S to i0, 
positive edge S to negative edge  in this version of X_BUFGMUX.vhd and the 
error message is from the ghdl run time library (grt), grt-vital_annotate.adb, 
we can assumed ghdl is reporting that it isn't doing  a setup and hold time 
check  (and this is the first one of two setup and two hold checks in this 
X_BUFGMUX.vhd, unhappy about something).


As an aside the only thing this particular timing check can test is effectively 
cycle time for the faster of the two clocks on this clock buffer (i0 or i1) 
based on the Select (S) delay from a synchronous event driving S.  For a 
simulation just checking back annotation for an XOR gate, who cares?

The question is whether you can do any timing checks for setup and hold time?

SDF File Syntax
=

Looking at the SDF file for X_BUFGMUX:

  (CELL (CELLTYPE X_BUFGMUX_X)
(INSTANCE clk_BUFGP_BUFG)
  (DELAY
(ABSOLUTE
  (IOPATH I0 O ( 0 ))
  (IOPATH I1 O ( 0 ))
)
  )
  (TIMINGCHECK
(SETUPHOLD (posedge S) (negedge I0) (480:600:600)(0))
  )
  )
There are two timing rvalues passed (480:600:600) and (0)  (in pico seconds, 
TIMESCALE from the SDF Header) the first three case times for setup time and 
the second 0 hold time.  (Keeping in mind I don't have

Re: [Ghdl-discuss] Using ghdl together with the Xilinx ISE tool chain

[David Koontz]

On Jan 6, 2012, at 12:17 PM, Walter F.J. Mueller wrote:

  on ghdl-discuss in July 2007. Unfortunately all written there still
  holds, one gets an error like
 
tb_x:error: x_tsim.sdf:9:16: ':' (colon) expected
 
  and ghdl aborts. ghdl doesn't accept the sdf files generated by the ISE
  tool chain.

I take it this was you?  bug #9597 https://gna.org/bugs/?9597 

Your 2007 post

works also if sdf annotation isn't enabled. If ghdl is started with
the appropriate --sdf qualifier, however, one gets the error

  tb_x:error: x_tsim.sdf:9:16: ':' (colon) expected

Apparently ghdl doesn't like the two lines

  (VOLTAGE 1.14)
  (TEMPERATURE 85)

If they are commented out, one gets

  tb_x:error: x.sdf:12:12: bad instance or celltype mistmatch

While the bug


% bin/tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu/simu_tb_test_timesim.ghw 
bin/tbx_test:error: test_timesim.sdf:14:12: bad instance or celltype mistmatch


Your original message shows an SDF file with only a single voltage and 
temperature case.  The reported bug shows three cases (and no complaints about 
a lack of colon).

There isn't anything apparently wrong with the test case sdf file, and nothing 
significant in the differences between the sdf 2.1 specification (used by 
Tristan originally) and sdf 3.0.

I take it the captured simulation model is in bin and named tbx_test?

UUT given as PATH is the TOP of the compiled model or is it?

Looking at test_arch of test we only get an unlabeled process statement while 
Structure of test (the PAR model) has the labels ci_IBUF, ci_IFF_IMUX,  
cj_IBUF,  cj_IFF_IMUX,  clk_BUFGP_IBUFG, co_OBUF, reset_IBUF, clk_BUFGP_BUFG, 
clk_BUFGP_BUFG_SINV,  clk_BUFGP_BUFG_I0_USED, Mxor_co_xor_Result1, 
co_OUTPUT_OFF_O1INV, co_OUTPUT_OFF_OSR_USED, co_OUTPUT_OFF_OMUX, 
co_OUTPUT_OTCLK1INV, co_0,   GLOBAL_LOGIC1_VCC (no timing), 
NlwBlock_test_GND (no timing),  NlwBlock_test_VCC (no timing),  NlwBlockROC 
(not involved), NlwBlockTOC (not involved).

We look in tb_test_timesim.vhd (TBX_ARCH of TBX_test) and we find 

UUT : test
  port map (
clk = clk,
ci = ci,
cj = cj,
co = co,
reset = reset
  );
In other words by default the last compiled architecture of test will be used.  
We have two, one test_arch has no labels matching the sdf file, the other 
Structure having labels matching and Cell types matching - which is what the 
error is complaining about.

This particular test case looks intended for SDF 95  (primitive/other instead 
of primitive/mti). Any testing effort we'lll stick with that.

setenv SIMPRIMS ~/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims
setenv OTHER $SIMPRIMS/primitive/other

ghdl -a --work=simprim $SIMPRIMS/simprim_Vcomponents.vhd
ghdl -a --work=simprim $SIMPRIMS/simprim_Vpackage.vhd
ghdl -a --work=simprim $OTHER/X_BUF.vhd
ghdl -a --work=simprim $OTHER/X_OBUF.vhd
ghdl -a --work=simprim $OTHER/X_BUFGMUX.vhd

Extra ordinary vital messages:

.../X_BUFGMUX.vhd:47:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:48:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:74:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:75:7: clock port name of 'ticd' VITAL generic must not appear 
here

ghdl -a --work=simprim $OTHER/X_INV.vhd
ghdl -a --work=simprim $OTHER/X_LUT4.vhd
ghdl -a --work=simprim $OTHER/X_SFF.vhd
ghdl -a --work=simprim $OTHER/X_ONE.vhd
ghdl -a --work=simprim $OTHER/X_ZERO.vhd
ghdl -a --work=simprim $OTHER/X_ROC.vhd
ghdl -a --work=simprim $OTHER/X_TOC.vhd


ghdl -a test_timesim.vhd
ghdl -a tb_test_timesim.vhd


david_koontz@Macbook: ghdl -r tbx_test --sdf=uut=test_timesim.sdf 
--stop-time=500us --wave=simu_tb_test_timesim.ghw
test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not bound
test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
ghdl:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o

Oops!  And this is the only one with a clock propagation delay.  Looks like 
VITAL checking needs to be disabled analyzing it.

So far there are two points to make:

First,

% bin/tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu/simu_tb_test_timesim.ghw 
bin/tbx_test:error: test_timesim.sdf:14:12: bad instance or celltype mistmatch

seems to be caused by analysis order of entity test architecture test_arch and 
architecture Structure in the original bug report.  In this case the only 
complaint was for the only timing value for an unbound component.

Second, 

test_timesim.vhd:133:3:warning: component instance clk_bufgp_bufg is not bound

Is going to require some finessing to analyze and elaborate.  The model 
(tbx_test) isn't complete without it. 
grep -i mux work-obj93.cf returns nothing.
(This is with the mcode version of GHDL-0.29 on Mac OS X).

From the header of X_BUFGMUX.vhd:

-- Revision:
--03/23/04 - Initial version.
--06/27/05 - 

Re: [Ghdl-discuss] postfitting timing simulation with XIlinx

[David Koontz]

On Jan 3, 2012, at 7:10 AM, René Doß wrote:

 That was a good hint,
 
 
 rm -rf work
 mkdir work
 ghdl -i *.vhd
 ghdl -i --work=simprim /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/*.vhd
 ghdl -i --work=simprim 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/mti/*.vhd
 ghdl -i --work=simprim 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/*.vhd
 ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic 
 --no-vital-checks --ieee=synopsys -fexplicit  tb_lm_cpu
 ../../../src/vital2000/timing_b.vhdl:196:15:warning: procedure vitalerror 
 is never referenced
 ../../../src/vital2000/timing_b.vhdl:217:15:warning: procedure vitalerror 
 is never referenced
 ../../../src/vital2000/prmtvs_b.vhdl:1041:15:warning: function toedge is 
 never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:391:14:warning: function 
 left_signed_arg is never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:400:14:warning: function 
 left_unsigned_arg is never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:409:14:warning: function 
 mult_signed_arg is never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:418:14:warning: function 
 mult_unsigned_arg is never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:1258:14:warning: function 
 unsigned_return_boolean is never referenced
 ../../../src/synopsys/std_logic_arith.vhdl:1266:14:warning: function 
 signed_return_boolean is never referenced
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:1199:18:warning:
  universal integer bound must be numeric literal or attribute
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:1229:18:warning:
  universal integer bound must be numeric literal or attribute
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB8BWER.vhd:1192:18:warning:
  universal integer bound must be numeric literal or attribute
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB8BWER.vhd:1222:18:warning:
  universal integer bound must be numeric literal or attribute
 analyze tb_lm_cpu.vhd
 analyze /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/simprim_Vcomponents.vhd
 analyze /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/simprim_Vpackage.vhd
 analyze lm_cpu_map.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_INV.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:1199:18:warning:
  universal integer bound must be numeric literal or attribute
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:1229:18:warning:
  universal integer bound must be numeric literal or attribute
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_BUF.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB8BWER.vhd
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB8BWER.vhd:1192:18:warning:
  universal integer bound must be numeric literal or attribute
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB8BWER.vhd:1222:18:warning:
  universal integer bound must be numeric literal or attribute
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_SFF.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_LUT6.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_LUT5.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_ZERO.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_CARRY4.vhd
 analyze /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_FF.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_ONE.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_OBUF.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_CKBUF.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_MUX2.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMD64_ADV.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_LATCHE.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_SRLC16E.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMD32.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_ROC.vhd
 analyze 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_TOC.vhd
 elaborate tb_lm_cpu
 red@linux-nrd1:~/projekt/mips/LM_CPU/ise/netgen/map ls
 e~tb_lm_cpu.o   lm_cpu_map.vsimprim-obj93.cf   tb_lm_cpu.o  
 work-obj93.cf  X_FF.o  X_LUT6.o  X_RAMB16BWER.o  X_ROC.o  X_ZERO.o
 lm_cpu_map.nlf  lm_cpu_map.vhd  simprim_Vcomponents.o  tb_lm_cpu.vhd
 X_BUF.oX_INV.o X_MUX2.o  X_RAMB8BWER.o   X_SFF.o
 lm_cpu_map.o  

Re: [Ghdl-discuss] postfitting timing simulation with XIlinx

[David Koontz]

On Jan 3, 2012, at 7:10 AM, René Doß wrote:

 ghdl -i --work=simprim 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/mti/*.vhd
 ghdl -i --work=simprim 
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/*.vhd

And I take it you're aware that anything in  the mti directory with the same 
entity/architecture name found in the other directory will get replaced in 
simprim?

When executing those two steps above this is what I ended up with:

david_koontz@Macbook: more simprim-obj93.cf | grep RAMB16B
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd
 20110621053512.000 20120103155321.928:
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWE.vhd
 20110621053512.000 20120103155321.862:
david_koontz@Macbook: grep RAMB16B simprim-obj93.cf 
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd
 20110621053512.000 20120103155321.928:
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWE.vhd
 20110621053512.000 20120103155321.862:

grep mti *.cf
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/simprim_Vpackage_mti.vhd
 20110621053500.000 20120103155117.264:
file / 
/Users/david_koontz/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims/simprim_Vcomponents_mti.vhd
 20110621053500.000 20120103155117.237:



___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] postfitting timing simulation with XIlinx

[David Koontz]

On Dec 30, 2011, at 8:41 AM, René Doß wrote:

 Hallo,
 
 my functional simulation runs but on my FPGA I get trouble. Now I want to 
 research the mistake.
 For this I want to start a post fitting simulation.
 
 I have in the subdirectory /ise/netgen/map  all files what I need. the sdf 
 file and the lm_cpu_map.vhd.
 
 
 ghdl -i *.vhd
 ghdl -i --work=simprim  /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/*.vhd
 ghdl -i --work=simprim  
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/mti/*.vhd
 ghdl -i --work=simprim  
 /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/*.vhd
 ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic  
 --ieee=synopsys -fexplicit --sdf=/.=lm_cpu_map.sdf  tb_lm_cpu
 ghdl: unknown option '--sdf=/.=lm_cpu_map.sdf' for command '-m'
 make: *** [all] Error 1
 
 How is the correct command line for the integration of sdf file?

ghdl --run-help

 ...
 --sdf=[min=|typ=|max=]TOP=FILENAME
annotate TOP with SDF delay file FILENAME
 ...

Loading an sdf file occurs at run time, which also tells you a model won't run 
as a standalone program with SDF delays loaded from an SDF file.  You could 
write something to produce (a) configuration statement(s) from SDF and 
configure a VITAL compliant model overloading generics conveying delay values.  

Back annotating in the simulator can add delays without needing a VITAL 
compliant model.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] Ghdl does nothing. (Looks like a bug)

[David Koontz]

On Dec 13, 2011, at 11:26 PM, Serguey Zefirov wrote:

 Thank you very much.
 
 Will code in runningSumMaybes_1 remain synthesable if I add my own
 add(l,r) and change code along your lines?

The numeric_bit or numeric_std library is just behavior.  The meaning of what 
you create by synthesis is mapped by convention (synthesizable constructs), and 
can some times be optimized for either speed or area, although just about 
everything is just speed these days (8 bit adders aren't too impressive in 
terms of area).  

The synthesis tool likely understands l+r where l and r are unsigned vectors 
(defined either in numeric_bit or numeric_std).  It'll map that into the 
appropriate macro or gate level construct.  It may not know how to map a ripple 
adder or a discrete logic adder efficiently because it doesn't know add() is 
supposed to be mapped onto fast arithmetic as in the case of an FPGA. 

If you don't care about speed a ripple adder will do, if you do need a 
something a little better a procedure that does Carry Look Ahead may be good 
enough. If you absolutely need speed it may be worth trying to convert the 
function (and your testbench) to std_logic as I described.  It may work - you'd 
expect someone would have notice std_logic unsigned (vectors) not adding 
correctly by now.  Most synthesis tools will swallow std_logic gracefully.

There's also the case that you can have two different expressions for 
simulation (add(l,r) and synthesis (l + r), and use the original code for 
synthesis.  Whether or not you can get away with it is dependent on how you 
verify post synthesis.  If the synthesis tools can produce gate level model you 
can verify it against vectors from the RTL model (the one you have that you 
modified).  The proof is hardware (gate level model) matching functional 
simulation. If you can validate results otherwise (capturing from hardware 
itself) you wouldn't need a gate level VHDL representation.  

So the answer is you can probably figure out a way to make your project work.




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] My real values are not updated according to gtkwave

[David Koontz]

On Nov 30, 2011, at 1:04 AM, Svenn Are Bjerkem wrote:

 Hi,
 
 I am simulating some code involving reals.
 When I use ghdl and dump the data to ghw and inspect with gtkwave, the
 adc_real(i) values get updated twice and then never more.
 When simulating with modelsim, I see that the same code result in
 adc_real values being updated with one clock cycle latency as
 expected.
 The integer values are updated as expected.
 
 What could cause reals not to be updated?
 
g_dc_offset : for i in 1 to 4 generate
p_calc : process (clk) is
begin
if rising_edge(clk) then
adc_integer(i).I =  to_integer(signed(datain(i).I));
adc_integer(i).Q =  to_integer(signed(datain(i).Q));
--adc_real(i).I =  real(to_integer(signed(datain(i).I)));
--adc_real(i).Q =  real(to_integer(signed(datain(i).Q)));
adc_real(i).I =  real(adc_integer(i).I);
adc_real(i).Q =  real(adc_integer(i).Q);
end if;
end process;
end generate;
 

There's an incomplete picture presented by your concurrent generate statement 
by itself. There may not necessarily be enough to reproduce your bug without 
extensive work.

Please provide the type and subtype declarations that go with these signals, 
values you know aren't getting converted would help as well as the results 
(expected and actual).  Historically Tristan has preferred a 'reproducer' a 
small standalone model that demonstrates a bug.  I'd suspect something is 
getting type confused due to using record elements.  Determining that would 
require knowing type and subtype declarations. If your sequential signal 
assignments in  for the adc_integer are working that they are for adc_real 
assignments too.  The model would then be giving you the same wrong result.

I checked and ghdl uses 64 bit values for Universal Integers and Reals, so 
conversion running into truncation based on mantissa accuracy would involve big 
integers or type confusion. Type conversion is supposed to work between any 
abstract numerical types and presenting a value out of range for the target is 
supposed to generate an error.

The generate statement contains a process, so during elaboration you'll get 
four block statements each with a process statement with static expressions 
replacing i.The signal assignment statements in each process statement are 
sequential and you derive the input to the real I and Q registers from the 
first saved integer I and Q registers (as shown with the commented lines).  If 
your integer registers show value changes then it's not a model execution 
problem.  There's an implicit 'wait on clk;' after the end if end statement in 
each process statement.

I take it the generate statement contains the only drivers for adc_real(i).I 
and adc_real(i).Q?

The preferred error reporting mechanism is through the Gna site as provided by 
the Report a bug link on ghdl.free.fr. Unfortunately you'll find that a Gna 
login is required to log a bug but it does give the developer(s) a way to 
contact you as well as the ability to upload a substantial amount of 
information you may have accumulated on a bug (like a reproducer).




___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] My real values are not updated according to gtkwave

[David Koontz]

On Dec 5, 2011, at 11:01 AM, Svenn Are Bjerkem wrote:

 Ok, It could have been something wrong with my code or some feature
 not implemented which caused the observation. Taken that it needs
 further investigation, I will take the effort to create a gna user and
 report the incident in a more appropriate way.

Troubleshooting something for the non-ghdl author means literally hours of VHDL 
'lawyering' to understand precisely what is supposed to happen followed by 
analysis of Ada source in ghdl to determine compliance.  Supplying more 
information can tell us where to look and save lots of time.  I'd  be willing 
to bet you could write something with generate statements that works simply by 
minimizing the number of types and subtypes involved (I'm suspicious of a class 
of problems with ghdl).  In general if your design works in Modelsim, there's a 
high likelihood it should work in ghdl.  

There don't appear to be any applicable standard changes that would imply 
different functionality in Modelsim compliant to a newer VHDL LRM standard  
(and ghdl is mostly VHDL-93 compliant with several features from 02 and 08). 
Reading a little further the version of  Modelsim supporting 64 bit values 
(other than Time) might be limited.

Without more information it sounds like a bug, but I can neither confirm nor 
deny.  You can post something that demonstrates the problem here instead of 
getting a Gna account.

Knowing the values you can demonstrate the problem with, types and sub type 
declarations are the important thing.  

It could even be a problem with mapping reals to ghw. Which reminds me, you 
could try assertion or report statements and use the predefined attribute 
'IMAGE to output values to separate gtkwave related issues.  

If the integer values work but not reals than it's in type conversion for 
reals, and likely caused by ghdl fumbling types or subtypes (there'd be a bug 
lurking in there).

It could even be an instrumentation problem.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Re: [Ghdl-discuss] A bug.

[David Koontz]

On 18/11/2011, at 6:09 AM, Serguey Zefirov wrote:

 It said a.vhd:10:21: no matching resolution function for 'x_res'.
 
 If I delete subtype x is rec; line and make x a record instead of
 subtype, all went fine.
 
 This is clearly a bug.

I'm afraid to see your resolution function with 3 or more elements in a record. 
 I've seen Ben Cohen's book Real chip design and verification using Verilog and 
VHDL and am aware of Jim Lewis wanting to do introspection.  The idea being to 
have some set of default functions for dealing with record elements instead of 
making the VHDL code author grow their own.  Integers do seem a little extreme.


Another way to eliminate the analysis error would be to change rec to a 
non-record type:

entity a is end entity a;

architecture b of a is
type rec is ('A','B','C','D'); -- type rec is record
--   a : integer;
--   end record;
subtype x is rec;
type x_vec is array (natural range ) of x;
function x_res(to_resolve : x_vec) return x;
subtype rx is x_res x;
function x_res(to_resolve : x_vec) return x is
variable r : x;
begin
--   r.a := 0;
   return r;
end function x_res;
begin
end architecture b;


Which matches how std_logic_1164 implements std_logic_vector in a package.  
Translating to a package:

package a_pkg is

type rec is ('A','B','C','D'); --  type rec is record
--  a : integer;
--  end record;
  subtype x is rec;
  type x_vec is array (natural range ) of x;
  function x_res (to_resolve: x_vec) return x;
  subtype rx is x_res x;
end a_pkg;

package body a_pkg is
  function x_res (to_resolve: x_vec) return x is
variable r: x;
begin
--  r.a := 0;
  return r;
end function x_res;
end a_pkg;

And the behavior matches.  So it's clearly unhappy about the subtype 
declaration for the record possibly due to it being an unconstrained subtype 
(because as you point out removing the subtype declaration passes analysis):

entity a is end entity a;

architecture b of a is
type x is record -- type rec is record
   a : integer;
   end record;
--subtype x is rec;
type x_vec is array (natural range ) of x;
function x_res(to_resolve : x_vec) return x;
subtype rx is x_res x;
function x_res(to_resolve : x_vec) return x is
variable r : x;
begin
   r.a := 0;
   return r;
end function x_res;
begin
end architecture b;



The error message 

   a.vhd:10:21: no matching resolution function for 'x_res' 

occurs in sem_types.adb, procedure Sem_Resolution_Function () which peforms two 
predicate tests (functions) - Is_Overload_List() and if that fails 
Is_A_Resolution_Function(). 

The purpose is to return the IIR resolution function 'pointer'.  You get the 
error when it doesn't get returned.

The overload test determines whether names are overloaded and whether they can 
be clearly distinguished.  That can involve calling Is_A_Resolution_Function() 
as well.

If there is no requirement to resolve overloaded names Is_A_Resolution_Function 
() is called.


First Off this is in the context of IEEE Std 1076-1993 (VHDL-93,V93). ghdl is 
mostly VHDL-93 compliant and iss capable of V87 compliance in this bit, but not 
V08.

Analyzing x_res for name overload isn't an issue when analyzing a.vhdl (entity 
a, architecture b of a).  There appears no particular difference in scope and 
visibility for a type declaration versus a subtype declaration.  More than 
likely this occurs in one of the four semantic checks in 
Is_A_Resolution_Function() found in the second paragraph of section 2.4 
Resolution functions (IEEE Std 1076-1993):

A resolution function must be a pure function (see 2.1); moreover, it must have 
a single input parameter of class constant that is a one-dimensional, 
unconstrained array whose element type is that of the resolved signal. The type 
of the return value of the function must also be that of the signal. Errors 
occur at the place of the subtype indication containing the name of the 
resolution function if any of these checks fail (see 4.2).

 --

The error message during analysis of a.vhdl occurs when a valid resolution 
function pointer has not been found.

The four semantic checks are in 7 different evaluations in Is_A_Resolution 
Function() I did modify a copy of sem_types.adb to see which if any of them 
fails once I get a development environment back together. The underlying 
problem may exhibit other symptoms, too.

As far as Gna being unfriendly, I don't have full control of ghdl there, nor 
can I upload releases to ghdl.free.fr which apparently requires the originating 
point to be within free.fr.  There's also the issue of numbers of ghdl 
contributors.  I figure it's more than a man year to go through and make ghdl 
fully VHDL-93 compliant including a sizable audit and setting up regression 
testing.  

Tristan spent the last couple of years in bug fix mode because of lack of 
qualified help and is currently off doing intensive Ada stuff.  He does notice 
when bugs are reported to Gna. We've talked about re-hosting ghdl but what we 

Re: [Ghdl-discuss] ghdl and ghdl.free.fr

[David Koontz]

On 30/09/2011, at 8:35 AM, Nathan Moore wrote:

 Hey,
 I saw that you are one of the developers for ghdl, and I was wondering
 how/where I could get the
 Win32 install for ghdl.  ghdl.free.fr seems to be gone, and I haven't
 been able to locate it elsewhere.
 I'm sorry to e-mail you directly, but I didn't think that this was a
 bug with ghdl itself.
 

I'm committing the faux pax of answering your email to ghdl-discuss because it 
may be relevant to other ghdl followers.  I'll Bcc you so your email address 
isn't uncovered and I don't have access to the mail subscriber lists to see if 
you're on it.

If you're having trouble accessing free.fr, it only lasts for 24 hours and is a 
Denial of Service attack defense that excludes entire domains - you could be 
suffering from the someone else's activities in your same domain (not readily 
apparent from your email).  I'd imagine say Google could regularly trip the DoS 
defense for instance.  

While I have (had) access to the download site, free.fr doesn't seem to allow 
binary images to be loaded to the site from outside the system.  Tristan had to 
load the Mac OS X version for me.  We've discussed moving the site, but our set 
of bias haven't matched and the urgency hasn't been there.

I don't personally have anything to do with a Windows version I did the one for 
Mac OS X.   As I recall Tristan addresses building in Windows environment, ghdl 
is a comand line interface only which means it could be done in cygwin etc.  I 
don't have a Windows machine and haven't paid close attention to problems if 
they weren't evident in the OS X version.

The ghdl download page is:

http://ghdl.free.fr/site/pmwiki.php?n=Main.Download

Older versions can be found at http://ghdl.free.fr/download.html and after 
Reading Brian Davis' message  
https://mail.gna.org/public/ghdl-discuss/2011-01/msg7.html I'd recommend 
the 0.29.1 version http://ghdl.free.fr/ghdl-installer-0.29.1.exe 

It seems the 
http://ghdl.free.fr/site/uploads/Main/ghdl-win-installer-latest.exe points to 
ghdl-installer-0.29.exe by examining the binary.  

If ghdl-0.29.1 isn't suitable (has problems, Brian Davis has commented on a 
problem with XP I believe)  Salvador E. Tropea's recent post has a pointer to a 
ghdl-0.25 for windows.  See 
https://mail.gna.org/public/ghdl-discuss/2011-09/msg1.html  He includes 
gtkwave in his package.

While I don't have a Windows build environment, something like Cygwin would do 
readily, it's only a command line interface.  Tristan addresses building a 
Windows version in various descriptions found in the source tree which can be 
downloaded via the SVN repository.
( see https://gna.org/svn/?group=ghdl ) 

Somewhere I did a list of svn revision levels to ghdl release numbers, and 
would examine the Bugs and Open Items for advising which one to use for a 
Windows build.  Building would require an Ada compiler.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss