Problem using $recordvars/$recordfile under NCverilog

[Hans]

The solution is simple, just call the annotate from the test module as in:

module test;
wire w;
block b1 ();
annotate annotate();
endmodule


No were is that beginners guide to verilog.....

Hans.


"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
news:ezpNc.186$ld7.154@newsfe6-gui.ntli.net...

Hi,

Can anybody tell me how to instantiate a verilog netlist + annotate module
(defparam) in a VHDL testbench?

I have created a simple testcase:

-- VHDL TestBench instantiating Verilog Module
use ieee.std_logic_1164.all;
entity tb is
end tb;
architecture arch of tb is
component test
end component;
begin
uut: test;
end arch;

-- Verilog Module and Annotate Module
module test;
wire w;
block b1 ();
endmodule

module block;
parameter p=1;
endmodule

module annotate;
defparam test.b1.p=2; // works for Verilog only
//defparam tb.uut.test.b1.p=2; //fails
//defparam /tb/uut.test.b1.p=2; //fails
//defparam /tb/uut/test.b1.p=2; //fails
endmodule


If I just load the verilog module it works fine (using Modelsim):

vlog test.v
vsim -c test annotate
examine sim:/test/b1/p -> p=2!

Instantiating the Verilog test module in a VHDL testbench is no problem,
however, how to update the parameter 'p'?

If I use:

vlog test.v
vcom tb.vhd
vsim -c tb annotate

I get: * Error: (vsim-3043) test.v(12): Unresolved reference to 'test' in
test.b1.p.


I then tried several defparam permutations all without any luck. If you
take
out the annotate module the simulation runs fine but with p=1.

I suspect that you can not reference a parameter through a VHDL entity but
I
just want to make sure that is the case,

Thanks,
Hans.

 

[Hans]

The solution is simple, just call the annotate from the test module as in:

module test;
wire w;
block b1 ();
annotate annotate();
endmodule


No were is that beginners guide to verilog.....

Hans.

"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
news:ezpNc.186$ld7.154@newsfe6-gui.ntli.net...
Hi,

Can anybody tell me how to instantiate a verilog netlist + annotate
module
(defparam) in a VHDL testbench?

I have created a simple testcase:

-- VHDL TestBench instantiating Verilog Module
use ieee.std_logic_1164.all;
entity tb is
end tb;
architecture arch of tb is
component test
end component;
begin
uut: test;
end arch;

-- Verilog Module and Annotate Module
module test;
wire w;
block b1 ();
endmodule

module block;
parameter p=1;
endmodule

module annotate;
defparam test.b1.p=2; // works for Verilog only
//defparam tb.uut.test.b1.p=2; //fails
//defparam /tb/uut.test.b1.p=2; //fails
//defparam /tb/uut/test.b1.p=2; //fails
endmodule


If I just load the verilog module it works fine (using Modelsim):

vlog test.v
vsim -c test annotate
examine sim:/test/b1/p -> p=2!

Instantiating the Verilog test module in a VHDL testbench is no problem,
however, how to update the parameter 'p'?

If I use:

vlog test.v
vcom tb.vhd
vsim -c tb annotate

I get: * Error: (vsim-3043) test.v(12): Unresolved reference to 'test'
in
test.b1.p.


I then tried several defparam permutations all without any luck. If you
take
out the annotate module the simulation runs fine but with p=1.

I suspect that you can not reference a parameter through a VHDL entity
but
I
just want to make sure that is the case,

Thanks,
Hans.

 

[Blackie Beard]

"Blackie Beard" <bb@fearlessimmortalwretch.com> wrote in message
news:ZrtOc.3057$8k.1843@fed1read03...

"Ted Larson" <ted@corticalsoftware.com> wrote in message
news:ce3jhl$f0h@dispatch.concentric.net...
Excellent suggestions! This is exactly what I needed....whew. I
thought
I
was going to drive myself crazy trying to figure that one out. I will
definitely try to keep all the LHS work of registers within the same
always
block from now on. That was the problem for sure. I attached a
synthesizable version below so you can see the changes I made based upon
your suggestions. Yay! No more warnings or errors!

What's funny is that a lot of simulators will let you get away with stuff
like that. Simulators only look for certain types of errors. But
synthesis tools will let you get away with other types of errors, as
long as it thinks there's a chance they could be intentional.



Additionally, for later portability, you should design with
just one clock, so all your circuits are singing to the same
hymnal. But you are using flick as another clock by
referencing to it's edge. Instead, use flick as a condition.


HOWEVER, this question brings up a larger question on my whole design.
I
had two clocks in there because what I am trying to do, is build a pulse
counter, that stores a total number of pulses, and then I can retrieve
them
using an externally clocked serial connection (SPI like). One clock is
the
pulses I want to count. The other clock is used for clocking the serial
data out at my leisure.

Given the problem I am trying to solve...and obviously for general types
of
scenarios like this one.....do you think it is a better overall
practice,
to
just have one master clock that is considerably faster than all the
clocking
conditions I have, and then just poll the two other clock lines? Or do
you
think it is better to have everything edge-triggered like I have done
below?


I'm assuming your pulse count is going to be much lower than your free-
running counter (which you are using to time the periodic communication).
No - you can certainly use the same clock for both.

Now you have to count, for example, posedge of incoming, and you are
using a different posedge for system clk. run the posedge of incoming
into the set of an RSFF, and run the RSFF's reset to it's output anded
with system clock == 1. (If the incoming pulsewidths are guaranteed by
design to be less than your system clock, this should work well). I
myself
hate using primatives and megafunctions, or whatever. I like to use fully
behavior code, so for that one I would make the RSFF out of combinatorial
loop logic (as long as you provide reset it's cool). I have one working
but
I've got to run to work - get back later.

BB

Yeah, you need like this:

wire ain1, aout1;
assign #1 aout1 = ain1 | (hold & aout1);
// (the "#1" is needed for simulation).
assign ain1 = pulse_input; // that you are trying to measure
assign hold = ~clk; // clk will clear the flop after you've got edge
captured

....
else if (aout1) counter <= counter + ?'h1; // increment positive edge
count

Thanks again for all your help. Very good info.

- Ted
ted@larsonland.com

This one will synthesize now:

module sercount4(clk,flick,set,reset,sout);
input clk;
input flick;
input set;
input reset;
output sout;

reg [7:0] count;
reg [7:0] tbuf;

always @(posedge clk or posedge set)
begin
if(set)
tbuf <= count;
else
tbuf <= tbuf << 1;
end

always @(posedge flick or posedge reset)
begin
if(reset)
count <= 8'h00;
else
count <= count+1;
end

assign sout = tbuf[7];

endmodule

 

[Blackie Beard]

"Blackie Beard" <bb@fearlessimmortalwretch.com> wrote in message
news:EXQOc.6545$8k.1083@fed1read03...

"Blackie Beard" <bb@fearlessimmortalwretch.com> wrote in message
news:ZrtOc.3057$8k.1843@fed1read03...

"Ted Larson" <ted@corticalsoftware.com> wrote in message
news:ce3jhl$f0h@dispatch.concentric.net...
Excellent suggestions! This is exactly what I needed....whew. I
thought
I
was going to drive myself crazy trying to figure that one out. I will
definitely try to keep all the LHS work of registers within the same
always
block from now on. That was the problem for sure. I attached a
synthesizable version below so you can see the changes I made based
upon
your suggestions. Yay! No more warnings or errors!

What's funny is that a lot of simulators will let you get away with
stuff
like that. Simulators only look for certain types of errors. But
synthesis tools will let you get away with other types of errors, as
long as it thinks there's a chance they could be intentional.



Additionally, for later portability, you should design with
just one clock, so all your circuits are singing to the same
hymnal. But you are using flick as another clock by
referencing to it's edge. Instead, use flick as a condition.


HOWEVER, this question brings up a larger question on my whole design.
I
had two clocks in there because what I am trying to do, is build a
pulse
counter, that stores a total number of pulses, and then I can retrieve
them
using an externally clocked serial connection (SPI like). One clock
is
the
pulses I want to count. The other clock is used for clocking the
serial
data out at my leisure.

Given the problem I am trying to solve...and obviously for general
types
of
scenarios like this one.....do you think it is a better overall
practice,
to
just have one master clock that is considerably faster than all the
clocking
conditions I have, and then just poll the two other clock lines? Or
do
you
think it is better to have everything edge-triggered like I have done
below?


I'm assuming your pulse count is going to be much lower than your free-
running counter (which you are using to time the periodic
communication).
No - you can certainly use the same clock for both.

Now you have to count, for example, posedge of incoming, and you are
using a different posedge for system clk. run the posedge of incoming
into the set of an RSFF, and run the RSFF's reset to it's output anded
with system clock == 1. (If the incoming pulsewidths are guaranteed by
design to be less than your system clock, this should work well). I
myself
hate using primatives and megafunctions, or whatever. I like to use
fully
behavior code, so for that one I would make the RSFF out of
combinatorial
loop logic (as long as you provide reset it's cool). I have one working
but
I've got to run to work - get back later.

BB


Yeah, you need like this:

wire ain1, aout1;
assign #1 aout1 = ain1 | (hold & aout1);
// (the "#1" is needed for simulation).
assign ain1 = pulse_input; // that you are trying to measure
assign hold = ~clk; // clk will clear the flop after you've got edge
captured

...
else if (aout1) counter <= counter + ?'h1; // increment positive edge
count

Come to think of it - this may not work because the flop after clearing
will continue to acquire because your pulse is still high.

You don't need then an RSFF. You just need to capture the edge,
right?

reg r1, r2;

always @(posedge clk)
begin
r1 <= pulse_in;
r2 <= r1;
end

assign increment_counter = (r1 == 1 & r2 == 0);

That should work.

Thanks again for all your help. Very good info.

- Ted
ted@larsonland.com

This one will synthesize now:

module sercount4(clk,flick,set,reset,sout);
input clk;
input flick;
input set;
input reset;
output sout;

reg [7:0] count;
reg [7:0] tbuf;

always @(posedge clk or posedge set)
begin
if(set)
tbuf <= count;
else
tbuf <= tbuf << 1;
end

always @(posedge flick or posedge reset)
begin
if(reset)
count <= 8'h00;
else
count <= count+1;
end

assign sout = tbuf[7];

endmodule

 

[Antti Lukats]

"sundar" <asundar@tenet.res.in> wrote in message
news:1324caeb.0407290458.3ac39ce3@posting.google.com...

Hi,
I am doing AC 97 audio interface to our project.We are using Xilinx
Microblaze
softprocessor core.This processor has two buses 1.LMB (for accessing
internal memory)2.OPB(External peripherals are attached to this).I
planned to use opencore AC 97 controller (verilog code)which has
Wishbone interface.I have to interface this with OPB bus.I want to
know whethere anyone worked on this already?Is there any bridge
available for this or is there any example bridge design between any
other buses?

Thanks for everything...

Please contact ASICS www.asics.ws
(sure others have solutions as well)

Antti
http://stores.ebay.com/OpenChip-Online-Shop_IP-Cores

 

[Blackie Beard]

Thank you, Mr. Gasket. I'd be too afraid that
1. I'd be beheaded by muslim militants, and
2. After having me train a bunch of Indian "freshies" they'd toss me
out on my arse.

Is telecommuting a possibility?

; )


"GSK1976" <gsk1976@yahoo.com> wrote in message
news:81c80799.0407310148.2239de54@posting.google.com...

Hi To All,

How are you!

Please send your resumes to Gsk1976@Yahoo.com or Gsk1976@Hotmail.Com
or Gsk1976@Rediffmail.com

PLEASE Forward this mail to your Friends,Colleagues,Seniors,Groups
etc. or/and apply yourself.

*** Freshers please DO NOT APPLY.

*** Rush your resumes in RTF/DOC format

*** Your Resume will be accorded high confidentiality.

*** Salary is not a constraint for the right candidate.


My Esteemed MNC Client are currently looking for Project Managers,
Project
Leaders and Senior Engineers with 3+ years of relevant
work experience in ASIC and Embedded Technologies:

ASIC Skill Sets: Verification and Design area

ˇ Verilog/VHDL modeling/design & Logic verification.
ˇ Complex ASIC/ SoC verification environments using
HDLs, C, OOP concepts, C++, PLI, Automated Unix
scripting (Perl, Tcl, shell), Specman, SystemC
ˇ Languages such as “e”, Testbuilder or C/C++ based
environments, HVL tools
ˇ Verification component development
ˇ Code coverage tools
ˇ Core Architecture development
ˇ RTL Design in Verilog/VHDL
ˇ FPGA and ASIC Synthesis experience
ˇ Static Timing Analysis
ˇ FPGA realization.

Embedded Skill Sets: Software and Hardware areas

§ RTOS, Networking and Processor Architecture
ˇ BSP Porting and Device drivers and middleware
(protocols, codecs, algorithms)
§ DSP software (MPEG2/4, JPEG, WMA, MP3 – Audio/Video
algorithms, optimization and porting) development
§ SAN and SCSI drivers
§ High Speed Board / hardware design
§ RISC processors based hardware design knowledge
preferred
§ DSP based design knowledge preferred
§ Assembly language and “C” programming for high-speed
Microprocessors / Microcontrollers

Regards,
Gsk1976

 

[Blackie Beard]

A glitch of infinitely short duration usually just means that
the simulator decided to evaluate an expression, then after
learning something else, came back around to reevaluate it.
I've never seen infinitely short duration signals that show up
in simulation that also appear in real hardware.

BB

"rsk" <krs_1980@yahoo.co.in> wrote in message
news:1e43bb10252c91a1cb8bff74f8d988c9@localhost.talkaboutprogramming.com...

Difference between glitch and jitters ?why and how they are formed?
I am getting glitches while simulating my modules,one more thing i
noticed is the glitches are forming for me only when iam using
delay evnts like #4,#20 ....
But when i am unsing the statement like
"repeat(1) @(posedge clk)" iam not getting any glitches.

Will u kindly clarify me why is it so?

 

[y_p_w]

General Schvantzkoph wrote:

Negotiating with the author is the right thing to do. I don't think it's a
hardware vs software issue. RTL code is software in the same sense that C
code is. Synthesis is the same as compilation, the object code is just
different.

Releasing a generic gate-level netlist of this core probably isn't that
big a deal for my employer. However - we typically use proprietary
processes where we might not want to release gate names for non-
disclosure reasons. Also - many of our design flows have involved
flattened netlists, so which level of "combined object code" needs
to be released.

I've considered releasing my own open source IP. However - there's
gotta be something more HDL specific than the LGPL, and that won't
scare off the majority of companies that use assorted proprietary
resources.

The place that's fuzzier is the definition of linking. Is the
map stage of the process equivalent to the link stage for software. I.e if
you were to synthesize the LGPLed core by itself and then link the edf
file to a separate edf file that contains your code, is that the same as
linking to a library file? Since you are producing commericial hardware
you shouldn't take a chance. You need to get a letter from the owner of
the core saying what your rights are. Frankly the best thing to do is to
buy a commericial license from the copyright owners. If they won't sell
you one and if they won't define your rights in a letter then don't use
the core.

Something tells me the authors of these cores aren't interested in
making money.

 

[Phil Tomson]

In article <pan.2004.08.05.20.49.44.167875@yahoo.com>,
General Schvantzkoph <schvantzkoph@yahoo.com> wrote:

On Thu, 05 Aug 2004 12:51:28 -0700, y_p_w wrote:

Hi-

My manager asked me to try and find any techniques or possibly
available cores for a certain hardware function. I believe that
I've found what I'm looking for available as a Verilog IP core
released under the GNU Lesser Public License, V2.1. The core
seems to work very well, and is probably better than what I could
have produced myself. We plan on using this core as a distinct
component in a larger design.

My basic problem is that the LGPL doesn't seem to be well suited
to a "hardware description languages" such as Verilog or VHDL
which are really abstractions of electronic functions rather than
"software" per se. For the non-hardware guys, the HDL code is
typically "synthesized" into gates/transistors that eventually
become part of the semiconductor layout. The LGPL refers to terms
such as "object code" and "executables" that simply don't apply to
our hardware production flow. In essence, the final hardware
**IS** the executable.

I've gone over the LGPL multiple times, and it seems that the term
"work based on the library" refers only to actual modifications
or close coupling of code with the LGPL'ed component. I'm still
unclear (the language of the LGPL is mind-boggling) whether or
not we would be required to release (and to what extent) the other
source code that is used to develop this product.

Making our modifications to a publicly available open-source core
seems like a fair "price" for its use. We would have no problem
acknowledging that we used this core. My company has a website,
and we could make our mods (if any) available for download there.
My employer more than likely won't want to make our proprietary HDL
source code available though.

So I'll just sum up what we're looking at, what we'll do with it,
and what we can or would rather not do:

1) I've located an open-source Verilog description (released under
the LGPL) of a hardware function we'd like to use.
2) We would have no problem releasing our modifications of this
code or giving credit to the original author; it only seems
fair.
3) My employer would be extremely hesistant to release our other
HDL source code used in this design. Like most companies in
our industry, we are in the business of selling proprietary
hardware.
4) Much of the LGPL language doesn't seem to apply to the
hardware development flow.

Is this doable? It sounds like the LGPL was meant to allow for
open-source software to be used in otherwise proprietary products.
However - using the LGPL seems to be navigating a minefield in
this respect. The standard GPL makes things extremely clear -
you don't use it for proprietary products. In a worst case
situation, might it be possible to ask the author for permission
to use it under the terms of a different license (modified BSD
perhaps)?

Thanks in advance.

Yu-Ping Wang
Berkeley, California

Negotiating with the author is the right thing to do. I don't think it's a
hardware vs software issue. RTL code is software in the same sense that C
code is. Synthesis is the same as compilation, the object code is just
different. The place that's fuzzier is the definition of linking. Is the
map stage of the process equivalent to the link stage for software. I.e if
you were to synthesize the LGPLed core by itself and then link the edf
file to a separate edf file that contains your code, is that the same as
linking to a library file?

I would tend to think that what's being done is more analogous to static
liking than it would be to dynamic linking. The component will be
instantiated with the rest of the design. What is the executable in
this context - I would tend to think it is the resulting hardware.
I don't see how anything analogous to dynamic linking is possible
with hardware. Static linking is allowed by the LGPL AFAIK (there are
issues with dynamic linking, though). I'm really kind of skeptical about
the LGPL being the appropriate license in this context (of hardware). I
suspect that the author chose the LGPL because it is more friendly for
commercial use - the original poster needs to ask the author about this.

Since you are producing commericial hardware
you shouldn't take a chance. You need to get a letter from the owner of
the core saying what your rights are. Frankly the best thing to do is to
buy a commericial license from the copyright owners. If they won't sell
you one and if they won't define your rights in a letter then don't use
the core.

Definately he should contact the author to ask what his/her intent was for
using the LGPL in this context.

Phil

 

[roller]

"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
news:591da479.0408051151.3a1491d4@posting.google.com...

Hi-

My manager asked me to try and find any techniques or possibly
available cores for a certain hardware function. I believe that
I've found what I'm looking for available as a Verilog IP core
released under the GNU Lesser Public License, V2.1. The core
seems to work very well, and is probably better than what I could
have produced myself. We plan on using this core as a distinct
component in a larger design.

My basic problem is that the LGPL doesn't seem to be well suited
to a "hardware description languages" such as Verilog or VHDL
which are really abstractions of electronic functions rather than
"software" per se. For the non-hardware guys, the HDL code is
typically "synthesized" into gates/transistors that eventually
become part of the semiconductor layout. The LGPL refers to terms
such as "object code" and "executables" that simply don't apply to
our hardware production flow. In essence, the final hardware
**IS** the executable.

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

 

[Isaac]

On Sat, 7 Aug 2004 12:32:20 +0200, roller <trash_nospam@hotmail.com> wrote:

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

Even if they could do so, I'm not convinced that hardware generated

without permission from an HDL description infringes the HDL code.

Isaac

 

[Phil Tomson]

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:

"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
news:591da479.0408051151.3a1491d4@posting.google.com...
Hi-

My manager asked me to try and find any techniques or possibly
available cores for a certain hardware function. I believe that
I've found what I'm looking for available as a Verilog IP core
released under the GNU Lesser Public License, V2.1. The core
seems to work very well, and is probably better than what I could
have produced myself. We plan on using this core as a distinct
component in a larger design.

My basic problem is that the LGPL doesn't seem to be well suited
to a "hardware description languages" such as Verilog or VHDL
which are really abstractions of electronic functions rather than
"software" per se. For the non-hardware guys, the HDL code is
typically "synthesized" into gates/transistors that eventually
become part of the semiconductor layout. The LGPL refers to terms
such as "object code" and "executables" that simply don't apply to
our hardware production flow. In essence, the final hardware
**IS** the executable.


a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

But the original poster is trying to be honest & legal.

Phil

 

[roller]

"Barry Margolin" <barmar@alum.mit.edu> escribió en el mensaje
news:barmar-F4C159.13374107082004@comcast.dca.giganews.com...

In article <cf31a5013nr@enews3.newsguy.com>,
ptkwt@aracnet.com (Phil Tomson) wrote:

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

One could probably say the same thing about executable object code vs.
the high-level language source, especially when highly optimizing
compilers are used. Yet that doesn't prevent people from being
concerned about copyright violation of software.

well they can be concerned, but has anybody actually proved copyright
violation or patent infringement from executable code?
like i read in another post, it seems that windows networking sucked before
they started "using" TCP/IP from BSD

But I suspect that someone *could* reverse engineer an ASIC, just as
people have been able to decompile object code. You wouldn't get back
the exact source code that was used, but you should be able to see
enough of its structure to determine if it's very similar to the code
whose infringement is suspected.

yes, but let's say it's a Ethernet controller, if any controller wants to
comply with the standard it'll implement certain functionality, which in
principle, should be the same for all controllers, thus making very hard to
distinguish between two implementations.

In a world where we've managed to reverse-engineer the genome, object
code and ASIC circuits are relative child's play.

well it depends on what you call "reverse-engineer", if it's just making a
map of the whole DNA sequence, or if it's actually understanding it all, to
know what to change to do something, i think we're pretty far from the
second.
but i agree that reverse-engineer an ASIC can be done under certain
circunstances, i believe smartcard crypto chips are protected against
physical reverse engineer though.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 

[roller]

"Phil Tomson" <ptkwt@aracnet.com> escribió en el mensaje
news:cf31a5013nr@enews3.newsguy.com...

<snip>

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

But the original poster is trying to be honest & legal.

Phil

wow! well some big companies should learn from that then...$CO, M$, etc..
in anycase, i believe that people releasing the source code of something are
already agreeing with "not caring" who use it, whether it's because they
just dont care, or because they are altruists or whatever, the thing is that
i dont believe they'd prosecute anybody using their code, they just rely on
the people using their code to be honest (as the OP) enough to choose to use
it or not according to the license and rights the authors gave, GPL, LGPL,
etc
however i guess some of them might have some principles and beliefs and they
might not want their code to be used commercially.

 

[Byron A Jeff]

In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
->

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
->
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

-
->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

-
-I doubt you would have to release the rest of your HDL code.

This is bad moo-shoo. I'll clarify in a bit.

-
->4) Much of the LGPL language doesn't seem to apply to the
-> hardware development flow.
->
->Is this doable? It sounds like the LGPL was meant to allow for
->open-source software to be used in otherwise proprietary products.
->However - using the LGPL seems to be navigating a minefield in
->this respect. The standard GPL makes things extremely clear -
->you don't use it for proprietary products. In a worst case
->situation, might it be possible to ask the author for permission
->to use it under the terms of a different license (modified BSD
->perhaps)?
-
-It seems that you're in uncharted territory here. I suspect that, as you
-say, the LGPL doesn't really apply here to your final product.
-
-Essentially, you're taking an LGPL component written in an HDL and
-synthesizing it to another form that gets realized in hardware. The
-analogy _could_ be made to compiling and linking in the software world,
-however, the language of the LGPL (as you note) does seem to refer to
-software (object files and shared libraries) not hardware.

It's analogous. So you really have to step back to the intent of the rights
that the LGPL attempts to impart. Again I'll get to this a bit later.

-
-One thing that the LGPL is often interpreted to exclude is dynamic linking
-- you apparently can't produces a dll/so file and dynamically link against
-it. However, static linking is allowed by the LGPL. I don't know if
-that kind of analogy can be stretched to your situation with hardware.

It can. But that's all mechanism. The question is what is the right that
dynamic/static linking facilitates?

-I would tend to see what you're doing as being closer to 'static linking'
-than it is to 'dynamic linking'.

Actually I'll bet money it's worse than that. Hence the bad moo-shoo above.

-
-If I were you I would contact the author of your module and ask him what
-his intent was for putting it under the LGPL. It looks like perhaps we
-need some different type of Open Source license for hardware. As you say,
-the GPL makes it clear that you can't use said component in a proprietary
-system, but the LGPL seems unclear in this context.

OK. Enough dancing. Here's the rights that the LGPL attempts to impart:

1) Changes and attribution of the LGPL code follows GPL guidelines. In short
exactly point #2 above that the OP made. No problem here.

2) The second right I've dubbed the rebuild right. It's outlined in section
6 of the LGPL. In short it states that the end user must have access to
any items required to rebuild the system with an improved or updated LGPL
component. Note this makes the mechanism fuzzy. However it's what's going to
cause the death of this trail.

Let me give three quick examples, then proceed onto the current problem:

1) Typical Linux system has an app which uses an LGPL library. It's dynamically
linked. New library comes out. User installs and the app now uses the new
library. In effect the user can "rebuild" the system with a new library by
installing the library and running the app. The app can be a binary and no
source for that app (which I affectionately call yourcode) is required to
be released.

2) Typical embedded system consist of an assembler and linker which can link
libraries in. You have an embedded application that uses an LGPL library.
A newer better version of the library comes out. The user has the right
(and knows about it because the developer of yourcode had to inform them)
to rebuild the system using the newer library. Depending on the context the
user may have to be provided an linkable object file of yourcode, and possibly
even the linker too. Note that even if the user doesn't have any way to
upload the new firmware into the hardware, they still have the right to
rebuild the firmware with the newer library.

3) Another embedded system uses a compiler to generate code. No linker exists.
The JAL project (http://jal.sf.net) is a perfect example. Libraries are LGPL
licensed. Firmware is built by including the library into the yourcode
application and then compiling the whole shebang. Newer better version of the
library comes out. The user has rebuild rights. So the yourcode developer
has to provide the user the items necessary to rebuild. But since there's
no linker, the only way to rebuild yourcode with a new library is to use
the source of yourcode. So you must deliver yourcode's source to the user
to satisfy the rebuild right.

So now the question is how does the rebuild right fit within the context
of the Verilog build process? Since the core is licensed under the LGPL, users
have the right to rebuild their application with newer cores. Not that they'd
have anyway of loading this new combo to actual hardware. But the right
is delineated in the license and so in order to satisfy it, you must facilitate
the user's rebuild right.

Now it's all very silly. The LGPL simply wasn't written to be equipped to
handle the situation. But that's the author's licensing terms and you have
an obligation to abide by the probably unintended consequences of the
application of that license.

I'll bet money that the original code author really wanted to retain the
GPL nature of changes to their code, while dismissing the rebuild right.

But as written, you'd have to deliver to the end user whatever code and
tools rquired to get them to rebuild with an updated core.

If I were you I'd certianly go and ask the original authors about their intent.
I'd probably also ask them to relicense.

The need for an Embedded GPL needs to exists for situations like this. It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

Just my two cents. And watch out for that moo-shoo.

BAJ

 

[Byron A Jeff]

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:
-
-"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
-news:591da479.0408051151.3a1491d4@posting.google.com...
-> Hi-
->
-> My manager asked me to try and find any techniques or possibly
-> available cores for a certain hardware function. I believe that
-> I've found what I'm looking for available as a Verilog IP core
-> released under the GNU Lesser Public License, V2.1. The core
-> seems to work very well, and is probably better than what I could
-> have produced myself. We plan on using this core as a distinct
-> component in a larger design.
->
-> My basic problem is that the LGPL doesn't seem to be well suited
-> to a "hardware description languages" such as Verilog or VHDL
-> which are really abstractions of electronic functions rather than
-> "software" per se. For the non-hardware guys, the HDL code is
-> typically "synthesized" into gates/transistors that eventually
-> become part of the semiconductor layout. The LGPL refers to terms
-> such as "object code" and "executables" that simply don't apply to
-> our hardware production flow. In essence, the final hardware
-> **IS** the executable.
->
-
-a dumb question, how could anybody prove that you used their HDL code in an
-ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
-used somebody else's code, i dont think there's a way to know whether the
-ASIC contains code you wrote, or that somebody else wrote.

Advocating theft be deception are we? "Nobody can find out, so why not
just steal it?!!" I love to see situational ethics in action.

The LGPL author wants their stuff to be used. They also would like to get
updates to their core. They probably didn't realize the unintended consequences
of the LGPL whenb applied into embedded context.

But toe sweep it all under the rug isn't the right way to handle it.

You should simply go talk to the core's author, and ask for a copy relicensed
so that it can be used. The ZPL or BSD license comes to mind. Or write a
license similar to the LGPL but from section 6. In short, usage of the core
is unlimited, changes to the source of the core must be distributed along
with the core, and nothing that uses the core unmodified is subject to the
LGPL no matter the mechanism of comingling the free and non free code.

Then it would be a done deal.

BAJ
-
-

 

[roller]

"Byron A Jeff" <byron@cc.gatech.edu> escribió en el mensaje
news:cf4avs$ft6@cleon.cc.gatech.edu...

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:
-
-"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
-news:591da479.0408051151.3a1491d4@posting.google.com...
-> Hi-
-
-> My manager asked me to try and find any techniques or possibly
-> available cores for a certain hardware function. I believe that
-> I've found what I'm looking for available as a Verilog IP core
-> released under the GNU Lesser Public License, V2.1. The core
-> seems to work very well, and is probably better than what I could
-> have produced myself. We plan on using this core as a distinct
-> component in a larger design.
-
-> My basic problem is that the LGPL doesn't seem to be well suited
-> to a "hardware description languages" such as Verilog or VHDL
-> which are really abstractions of electronic functions rather than
-> "software" per se. For the non-hardware guys, the HDL code is
-> typically "synthesized" into gates/transistors that eventually
-> become part of the semiconductor layout. The LGPL refers to terms
-> such as "object code" and "executables" that simply don't apply to
-> our hardware production flow. In essence, the final hardware
-> **IS** the executable.
-
-
-a dumb question, how could anybody prove that you used their HDL code in
an
-ASIC?, let's say it's an Ethernet core, if you dont explicitily mention
you
-used somebody else's code, i dont think there's a way to know whether the
-ASIC contains code you wrote, or that somebody else wrote.

Advocating theft be deception are we? "Nobody can find out, so why not
just steal it?!!" I love to see situational ethics in action.

you're putting words in my mouth, i asked a question, besides, dont tell me
you actually believe that nobody will do/have done it...
when was the last time you saw ethics "working" in the business?, business a
re business, dot.
in anycase i dont see a way to actually check if somebody use our free cores
in commercial products, not that there's anything wrong with that.

The LGPL author wants their stuff to be used. They also would like to get
updates to their core. They probably didn't realize the unintended
consequences
of the LGPL whenb applied into embedded context.

agreed, they wanted updates

But toe sweep it all under the rug isn't the right way to handle it.

You should simply go talk to the core's author, and ask for a copy
relicensed
so that it can be used. The ZPL or BSD license comes to mind. Or write a
license similar to the LGPL but from section 6. In short, usage of the
core
is unlimited, changes to the source of the core must be distributed along
with the core, and nothing that uses the core unmodified is subject to the
LGPL no matter the mechanism of comingling the free and non free code.

Then it would be a done deal.

that's fair, but again, i dont think that's something all companies would do

 

[y_p_w]

Byron A Jeff wrote:

So now the question is how does the rebuild right fit within the context
of the Verilog build process? Since the core is licensed under the LGPL, users
have the right to rebuild their application with newer cores. Not that they'd
have anyway of loading this new combo to actual hardware. But the right
is delineated in the license and so in order to satisfy it, you must facilitate
the user's rebuild right.

The LGPL language specifically mentioned the ability to reverse engineer.

Now it's all very silly. The LGPL simply wasn't written to be equipped to
handle the situation. But that's the author's licensing terms and you have
an obligation to abide by the probably unintended consequences of the
application of that license.

I'll bet money that the original code author really wanted to retain the
GPL nature of changes to their code, while dismissing the rebuild right.

But as written, you'd have to deliver to the end user whatever code and
tools rquired to get them to rebuild with an updated core.

Yeah right. Sure - I'll include a copy of the Cadence NC-Affirma
simulator and Synopsys Design Compiler. There actually aren't that
many good free HDL tools, although apparently one is called (ironically
enough) "GPL".

If I were you I'd certianly go and ask the original authors about their intent.
I'd probably also ask them to relicense.

The need for an Embedded GPL needs to exists for situations like this. It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

Well I recall Cisco got in trouble when they bought out Linksys. Didn't
Linksys use Linux components in many of their boxes, and they didn't
care if the OS could be reverse engineered? When Cisco ended up
releasing the product, they balked at the open-source requirements,
but ended up releasing the source code after there was a legal threat
to force them to do so.

Just my two cents. And watch out for that moo-shoo.

Like I said, it's a minefield.

Yu-Ping Wang
Berkeley, California

 

[Eyck Jentzsch]

Rolf Kemper wrote:

Hi ALL,

I want to start with PSL and NC-Verilog.
Most things are not yet clear to me.
What would help myself is some tiny example how psl statements
(assertions) are combined with the verilog code and how the simulator
will deal with it.

Any hint is welcome

Rolf
You should have a look at `ncroot`/doc/abvtutorial or use cdsdoc,

section 'ABV Tutorial'.

-Eyck

 

[glen herrmannsfeldt]

roller wrote:

(snip)

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

An ethernet core is about the only one I could imagine. One might
be able to show timing, side effects, or other unique signs of a
particular core from the outside. It might be specific enough
to prove its source.

-- glen