Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 156975

Article: 156975
Subject: Re: strange effect with tristate output
From: Gabor <gabor@szakacs.org>
Date: Sun, 10 Aug 2014 11:38:58 -0400
Links: << >>  << T >>  << A >>
On 8/7/2014 5:35 PM, Frank Buss wrote:
> Jon Elson wrote:
>>
>> 9500XL is a 3.3 V logic family that is safe for 5 V signal levels,
>> if series resistance is provided, but it will not drive 5V to
>> an output.  So, don't expect anything to work right with 5V pull-ups
>> to an output.
>
> Where did you read that it needs a series resistor? The famlily data
> sheet says on page 12:
>
> | The I/Os on each XC9500XL device are fully 5V tolerant
> | even though the core power supply is 3.3 volts. This allows
> | 5V CMOS signals to connect directly to the XC9500XL
> | inputs without damage.
>
> And I think it is safe to drive it as output with the pullup resistor.
> The 3k3 pullup allows a current of max 1.5 mA for the 5V, which should
> not cause any over voltage at the pin in output mode.
>
>> The 5 V tolerance is there only for connection of INPUTS to other
>> circuitry.  Anyway, it looks like the pull-up and pull-down
>> transistors don't get cleanly off the pad when you tell it to go to
>> Hi-Z.
>
> I changed the output slew rate from slow to fast and increased the main
> clock frequency in the UCF file (someday I'll learn the timing analyzer
> and how to setup proper timing constraints), now it looks like this:
>
> http://i.imgur.com/xtfL72j.png
>
> Not perfect, but should work for my project.
>

The effect of changing the slew rate seems to confirm the
suspicion that the output switches low at the same time the
tristate happens.  Can you look at the fitter output to see
if this is the case (look at the generated equations)?

-- 
Gabor

Article: 156976
Subject: Has anyone forked any Xilinx IP?
From: sp@orbitalfox.com (SP)
Date: Sun, 10 Aug 2014 15:39:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
What is the "recommended" way to do IP forking from Xilinx's repos? Not
for public distribution but to have a modified one for specific
purposes. The modifications are beyond the customisations offered by
generator.

Has anyone done it?

-- 
    Stavros

Article: 156977
Subject: Re: Has anyone forked any Xilinx IP?
From: sp@orbitalfox.com (SP)
Date: Sun, 10 Aug 2014 15:57:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
SP <sp@orbitalfox.com> wrote:
> Has anyone done it?

In case someone is wondering the same and no better answer comes I have
done the following in Vivado IDE.

* Created a new IP repo from "Manage IP"
* In the "project manager" window I clicked the "IP settings" button.
* Clicked "Add IP".
    - Found the IP from Xilinx's repo (Xilinx/Vivado/201x.x/data/ip/)
* Then I could click "Edit in Packager"

Not sure if this is the best way. Kinda worked. I will write and article
about it, but I must know if there are any better ways before I do so.

-- 
    Stavros

Article: 156978
Subject: Re: Basic question: sequence of execution within FPGAs
From: rickman <gnuarm@gmail.com>
Date: Sun, 10 Aug 2014 14:20:09 -0400
Links: << >>  << T >>  << A >>
On 8/8/2014 12:09 PM, Tim Wescott wrote:
>
> I agree with Allan's recommendation -- get a book on logic design with
> Verilog.  A good book will devote at least half of the content to
> language-independent issues, essentially telling you what you want to
> get.  The rest of the content will go into the differences between
> simulation and synthesis, how to write the code for synthesis, and how to
> structure your test bench to properly test the code that'll actually make
> an FPGA.

Most of my HDL background is with VHDL and I have only used Verilog when 
required.  I have asked a number of times about a good Verilog reference 
and been repeatedly told there aren't any.  Has that changed?  Do you 
have one you like?

-- 

Rick

Article: 156979
Subject: Re: Basic question: sequence of execution within FPGAs
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Sun, 10 Aug 2014 14:19:06 -0500
Links: << >>  << T >>  << A >>
On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

> On 8/8/2014 12:09 PM, Tim Wescott wrote:
>>
>> I agree with Allan's recommendation -- get a book on logic design with
>> Verilog.  A good book will devote at least half of the content to
>> language-independent issues, essentially telling you what you want to
>> get.  The rest of the content will go into the differences between
>> simulation and synthesis, how to write the code for synthesis, and how
>> to structure your test bench to properly test the code that'll actually
>> make an FPGA.
> 
> Most of my HDL background is with VHDL and I have only used Verilog when
> required.  I have asked a number of times about a good Verilog reference
> and been repeatedly told there aren't any.  Has that changed?  Do you
> have one you like?

I'm not really qualified to answer that.  By training I'm a designer of 
analog circuits, control systems, and low-level communications algorithms 
(i.e., detecting bits).  By experience I'm all of those, but my actual 
customer deliverables have been primarily lines of C or C++ code; a GOOD 
project is one where I'm backing that up with control or comms design.

I have done exactly one small job each with Verilog and VHDL, and the 
comment I got back from the (real) digital guys on my VHDL code was 
"you're a software guy, aren't you?" (well, no -- I'm an analog circuit 
designer who puts food on the table by writing C++ code, but I certainly 
LOOK like a software guy when the light is shining from a certain 
direction).

The books that I have are "The Verilog Hardware Description Language" by 
Thomas & Moorby, and the IEEE Verilog Standard.  Thomas & Moorby was 
selected because, out of the three books on the shelf at Powell's 
Technical Books that day in 2003, it was the one that seemed to be the 
most clear and informative.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 156980
Subject: Re: Basic question: sequence of execution within FPGAs
From: rickman <gnuarm@gmail.com>
Date: Sun, 10 Aug 2014 16:33:04 -0400
Links: << >>  << T >>  << A >>
On 8/10/2014 3:19 PM, Tim Wescott wrote:
> On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:
>
>> On 8/8/2014 12:09 PM, Tim Wescott wrote:
>>>
>>> I agree with Allan's recommendation -- get a book on logic design with
>>> Verilog.  A good book will devote at least half of the content to
>>> language-independent issues, essentially telling you what you want to
>>> get.  The rest of the content will go into the differences between
>>> simulation and synthesis, how to write the code for synthesis, and how
>>> to structure your test bench to properly test the code that'll actually
>>> make an FPGA.
>>
>> Most of my HDL background is with VHDL and I have only used Verilog when
>> required.  I have asked a number of times about a good Verilog reference
>> and been repeatedly told there aren't any.  Has that changed?  Do you
>> have one you like?

...snip...

> The books that I have are "The Verilog Hardware Description Language" by
> Thomas & Moorby, and the IEEE Verilog Standard.  Thomas & Moorby was
> selected because, out of the three books on the shelf at Powell's
> Technical Books that day in 2003, it was the one that seemed to be the
> most clear and informative.

The most important thing I would want from a Verilog book wasn't 
mentioned in your list of features of a good Verilog book, a description 
of the pitfalls of the Verilog language.  The issues you cover are all 
language independent in my opinion.  I once asked specifically about 
finding a book to cover the pitfalls and was told that none existed.  I 
asked again a year or two ago and was told the same thing.

Unfortunately I have become very accustomed to writing VHDL and have 
lost any strong desire to become as proficient in Verilog.  If "the" 
book becomes available I might buy it and finish my education, but I'm 
not expecting that to happen.

-- 

Rick

Article: 156981
Subject: Re: Basic question: sequence of execution within FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 10 Aug 2014 21:03:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

(snip)
>> Most of my HDL background is with VHDL and I have only used Verilog when
>> required.  I have asked a number of times about a good Verilog reference
>> and been repeatedly told there aren't any.  Has that changed?  Do you
>> have one you like?
 
(snip)

> I have done exactly one small job each with Verilog and VHDL, and the 
> comment I got back from the (real) digital guys on my VHDL code was 
> "you're a software guy, aren't you?" (well, no -- I'm an analog circuit 
> designer who puts food on the table by writing C++ code, but I certainly 
> LOOK like a software guy when the light is shining from a certain 
> direction).
 
> The books that I have are "The Verilog Hardware Description Language" by 
> Thomas & Moorby, and the IEEE Verilog Standard.  Thomas & Moorby was 
> selected because, out of the three books on the shelf at Powell's 
> Technical Books that day in 2003, it was the one that seemed to be the 
> most clear and informative.

Yes, and I would recommend it, too.  You want a nice reference
that you can look something up in when you need to.

Some will probably complain that it isn't up to date with the
newer standards, but most of the time that isn't a problem.

I like writing structural verilog, using continuous assignment
and module references, except that registers are in behavioral
verilog. I put the registers into a module, and just reference
that when I need one. (Like reg8 for an 8 bit register.)

Some people like behavioral verilog, as it is more similar to
writing software, but to me that distracts from the fact that
it isn't software.  Like analog circuits and digital logic, you
have to remember that everything happens all the time, not sequentially
like in C. If you think sequentially, you will write poor and
inefficient verilog (or VHDL). 

For those who grew up in the days of TTL (or MSI CMOS), thinking
about wiring up gates, I believe it is fairly easy to learn to
think in verilog. Think about wires and gates.  (And it shouldn't
be so hard for analog designers.)

But people used to thinking sequentially, like writing a C program,
will have a harder time. 

Now, consider the design of a digital clock. Years ago, you would
wire up some 7490 and 7492 counters, some 7447 (or maybe 7441)
decoders, and let them count away.  A little more recently, it
might be done with a microprocessor or microcontroller, probably
multiplexing the display. (That is, for those that don't use
an LSI clock chip.)  

In the case of a digital clock, you don't need anywhere near
the 10's of MHz that TTL can run at, and there is plenty of time
to update the display in a software loop. Both make inefficent
use of the available hardware resources, but that is fine.

-- glen


Article: 156982
Subject: Re: LVDS problem - Black magic anyone?
From: thomas.entner99@gmail.com
Date: Mon, 11 Aug 2014 00:16:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
> > What are you using for an LVDS receiver? (Any equalisation?)
> It is a Cyclone IVGX SerDes. Yes, equalization is active (at a medium
> setting).
> I will play around a little bit with this settings (unfortunately
> the compile-time is quite long).

It turned out that the equalization was too high. When increasing the setting, things got worse. When setting it to "low", things work perfect without any errors...

I think the great effects of touching the cable can be explained with the weak twisting of the pairs.

Regards,

Thomas

Article: 156983
Subject: Re: Has anyone forked any Xilinx IP?
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 11 Aug 2014 17:42:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <ls83nl$34c$1@dont-email.me>, SP <sp@orbitalfox.com> wrote:
>What is the "recommended" way to do IP forking from Xilinx's repos? Not
>for public distribution but to have a modified one for specific
>purposes. The modifications are beyond the customisations offered by
>generator.
>

We've had to do it.  The general rule is to quickly throw away any use
of Xilinx's "wizards" or other hold-your-hand GUIs.  Get to the 
straight RTL and just use that.  Most of Xilinx's current 
IP is unencrypted RTL - although buried deep within wrappers
and other "wizardly" cruft.

(This is generally good advise in any cases for any vendors IP, IMHO.
Throw away the wizards, and GUIs that just get in the way.  But I digress).

Now, it's simple. Just edit the RTL as needed and continue.

There's gotchas, and other things that you'll have to work through.
But they're all solvable.

Regards,

Mark



Article: 156984
Subject: Re: LVDS problem - Black magic anyone?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 11 Aug 2014 20:45:06 +0100 (BST)
Links: << >>  << T >>  << A >>
thomas.entner99@gmail.com wrote:
> It turned out that the equalization was too high. When increasing the
> setting, things got worse.  When setting it to "low", things work perfect
> without any errors...
> 
> I think the great effects of touching the cable can be explained with the
> weak twisting of the pairs.

I suspect the cable looks more like a parallel ribbon cable than twisted
pair.  That means there could be other signals between the twisted pair and
ground - eg if it turns out it goes:
GND RXD D+ D- TXD VCC

Any common mode currents, which there will be because your coding scheme is
not DC balanced, will flow around a loop with RXD or TXD in the middle, so
are likely to be inductively coupled with these wires (ie cause crosstalk). 
It's difficult to say what effect the inductance of this loop will have on
the LVDS signal (I suspect not a huge amount, but have no numbers: it will
depend on how quick the rise times are), but I wouldn't be surprised if you
saw coupling into the RXD and TXD wires.

Likewise, we'd have to know a bit more about the channel characteristics to
predict what the likely frequency response of the channel might be (you'd
model each part's LCR properties separately: hard numbers needed).

I'd guess that the touching effect increases both the capacitance to ground
and the inter-pair capacitance.  It moves the frequency nulls around - I'm
not familiar with the equalisation settings on that transceiver to know the
effect of the different modes, but it's not implausible that equalisation
could cope with one but not the other.  In theory your transmission line
should be correctly terminated so you don't need equalisation, but it very
obviously isn't.

Theo

Article: 156985
Subject: Re: LVDS problem - Black magic anyone?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 11 Aug 2014 21:12:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
thomas.entner99@gmail.com wrote:
> I have an LVDS related issue that drives me crazy:
 
> There are two boards with a FPGA that are connected by a ca. 
> 30cm cable. Only 6 wirea are used:
> GND + Power
> LVDS (with embedded clock), 720Mbps
> UART (Rxd + Txd)
> (The cable is unshielded for flexibility reasons)
 
> The cable is a "flat Ethernet cable" with 4 twisted pairs, 
> one pair is unused, one pair is LVDS, one pair is GND + Rxd 
> and the last is Power + TxD.

Ethernet cables use pin pairs (1,2) (3,6) (4,5) and (7,8).

With the usual cables, you can see the pairs, including the 
colors, in the connector.

I have one, though, which I would call flat, and which the pairs
are not visible. It is very thin and flexible, and seems to work
fine for 100baseTX. I suspect the wire is much smaller than the
normal Cat 5 wire.

But otherwise, ethernet cables are normally rated to 100MHz.
1000baseT uses a complicated signal system on all four pairs
(in both directions at the same time) to get the bits through.

I wouldn't be surprised if you could get 720MHz through Cat 5
cable for 30cm, but your cable might not be quite that good.

-- glen



Article: 156986
Subject: Re: Basic question: sequence of execution within FPGAs
From: jonesandy@comcast.net
Date: Mon, 11 Aug 2014 19:52:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
It is crucial to understand how synthesis works, but it is not necessary to=
 code a netlist of the HW you think will do what you want.

In 20+ years of VHDL-based FPGA development, I have made behavioral mistake=
s FAR more often than I have made HW design mistakes (in other words, the c=
ircuit was viable and reliable, it just didn't do what I wanted it to).

Writing the code such that the clock cycle behavior is at least as apparent=
, if not moreso, than the HW circuit helps avoid the most common mistakes.

Sure, there are cases where I have to code "closer to the HW" to get perfor=
mance or utilization where I need it, but those are few and far between. To=
o far to code that way all the time.

Learn what behaviors infer latches (bad), registers and ram (good). Study t=
he synthesis tool's examples for ram inference, but learn their behavior, n=
ot so much about how they happened to code that behavior. This will let you=
 write portable code that will work for multiple target FPGAs.

Describe the desired behavior on every clock cycle. Think in terms of behav=
ior and clock cycles of latency, rather than gates and registers. The latte=
r will go to pot as soon as you turn on retiming and pipelining optimizatio=
ns anyway.

Andy

Article: 156987
Subject: Re: Professional VHDL Examples?
From: ajpkane@gmail.com
Date: Wed, 13 Aug 2014 00:18:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, 1 August 2014 13:53:42 UTC+2, Allan Herriman  wrote:
> On Thu, 31 Jul 2014 09:34:52 -0700, wabac0 wrote:
>=20
>=20
>=20
> > Over the years I have taught myself Verilog and VHDL, and although I am
>=20
> > quite comfortable with Verilog, I feel as though my VHDL designs are
>=20
> > just not as tight as they should be.  In pursuit of self-improvement, I
>=20
> > am trying to find "real world" examples of professional VHDL designs
>=20
> > that I can glean for hints on how to make my designs better. I have rea=
d
>=20
> > many, many books and analyzed some projects on opencores, but everythin=
g
>=20
> > that I have seen seems a bit lacking.  I am hoping that the
>=20
> > comp.arch.fpga community might share a few examples of solid VHDL
>=20
> > designs that I can review. Incomplete designs are fine, as long as I ca=
n
>=20
> > get a feel for how you are accomplishing things. Bear in mind that I
>=20
> > will not critique your design, and am not interested in participating i=
n
>=20
> > The Great HDL Debate MMXIV: Part XXIII. I need to continue to use both
>=20
> > VHDL and Verilog.
>=20
>=20
>=20
>=20
>=20
> Here's an example of mine from 2002 or so.
>=20
>=20
>=20
> http://fractional-divider.tripod.com/fracn20.zip
>=20
>=20
>=20
> It shows how to use VHDL in a way that would be difficult to mimic in=20
>=20
> Verilog, and may seem strange to Verilog coders.  As such, it may be=20
>=20
> useful as a learning exercise.
>=20
>=20
>=20
> I have a Verilog version on that same web page, but it uses a Perl script=
=20
>=20
> to write the Verilog, customised by some command line parameters.  The=20
>=20
> VHDL version customises itself from its generics at elaboration time.
>=20
>=20
>=20
> Most of the code consists of functions that in many cases use floating=20
>=20
> point numbers to produce a bunch of constants that control the=20
>=20
> (relatively small) chunk of RTL at the bottom of the file.
>=20
>=20
>=20
> BTW, it isn't representative of code I write now, but it is still useful=
=20
>=20
> as a tool torture test.
>=20
>=20
>=20
> Regards,
>=20
> Allan

I'm interested in looking at this, but when I click on the link I get the f=
ollowing message:

This file is hosted by Tripod, a Lycos=AENetwork Site, and is not available=
 for download. Please check out Tripod's Help system for more information a=
bout Remote Loading and our Remote Loading policy.

Article: 156988
Subject: Re: Professional VHDL Examples?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 13 Aug 2014 12:50:15 GMT
Links: << >>  << T >>  << A >>
On Wed, 13 Aug 2014 00:18:49 -0700, ajpkane wrote:

> On Friday, 1 August 2014 13:53:42 UTC+2, Allan Herriman  wrote:
>> On Thu, 31 Jul 2014 09:34:52 -0700, wabac0 wrote:
>> 
>> 
>> 
>> > Over the years I have taught myself Verilog and VHDL, and although I
>> > am
>> 
>> > quite comfortable with Verilog, I feel as though my VHDL designs are
>> 
>> > just not as tight as they should be.  In pursuit of self-improvement,
>> > I
>> 
>> > am trying to find "real world" examples of professional VHDL designs
>> 
>> > that I can glean for hints on how to make my designs better. I have
>> > read
>> 
>> > many, many books and analyzed some projects on opencores, but
>> > everything
>> 
>> > that I have seen seems a bit lacking.  I am hoping that the
>> 
>> > comp.arch.fpga community might share a few examples of solid VHDL
>> 
>> > designs that I can review. Incomplete designs are fine, as long as I
>> > can
>> 
>> > get a feel for how you are accomplishing things. Bear in mind that I
>> 
>> > will not critique your design, and am not interested in participating
>> > in
>> 
>> > The Great HDL Debate MMXIV: Part XXIII. I need to continue to use
>> > both
>> 
>> > VHDL and Verilog.
>> 
>> 
>> 
>> 
>> 
>> Here's an example of mine from 2002 or so.
>> 
>> 
>> 
>> http://fractional-divider.tripod.com/fracn20.zip
>> 
>> 
>> 
>> It shows how to use VHDL in a way that would be difficult to mimic in
>> 
>> Verilog, and may seem strange to Verilog coders.  As such, it may be
>> 
>> useful as a learning exercise.
>> 
>> 
>> 
>> I have a Verilog version on that same web page, but it uses a Perl
>> script
>> 
>> to write the Verilog, customised by some command line parameters.  The
>> 
>> VHDL version customises itself from its generics at elaboration time.
>> 
>> 
>> 
>> Most of the code consists of functions that in many cases use floating
>> 
>> point numbers to produce a bunch of constants that control the
>> 
>> (relatively small) chunk of RTL at the bottom of the file.
>> 
>> 
>> 
>> BTW, it isn't representative of code I write now, but it is still
>> useful
>> 
>> as a tool torture test.
>> 
>> 
>> 
>> Regards,
>> 
>> Allan
> 
> I'm interested in looking at this, but when I click on the link I get
> the following message:
> 
> This file is hosted by Tripod, a Lycos®Network Site, and is not
> available for download. Please check out Tripod's Help system for more
> information about Remote Loading and our Remote Loading policy.

I just tested it and it downloaded fine for me.  It sounds like a problem 
at your end.

I emailed a copy to the email address in the header of your post.

Regards,
Allan

Article: 156989
Subject: Re: Basic question: sequence of execution within FPGAs
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 13 Aug 2014 09:51:36 -0500
Links: << >>  << T >>  << A >>
On 8/10/2014 3:33 PM, rickman wrote:
> On 8/10/2014 3:19 PM, Tim Wescott wrote:
>> On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:
>>
>>> On 8/8/2014 12:09 PM, Tim Wescott wrote:
>>>>
>>>> I agree with Allan's recommendation -- get a book on logic design with
>>>> Verilog.  A good book will devote at least half of the content to
>>>> language-independent issues, essentially telling you what you want to
>>>> get.  The rest of the content will go into the differences between
>>>> simulation and synthesis, how to write the code for synthesis, and how
>>>> to structure your test bench to properly test the code that'll actually
>>>> make an FPGA.
>>>
>>> Most of my HDL background is with VHDL and I have only used Verilog when
>>> required.  I have asked a number of times about a good Verilog reference
>>> and been repeatedly told there aren't any.  Has that changed?  Do you
>>> have one you like?
>
> ...snip...
>
>> The books that I have are "The Verilog Hardware Description Language" by
>> Thomas & Moorby, and the IEEE Verilog Standard.  Thomas & Moorby was
>> selected because, out of the three books on the shelf at Powell's
>> Technical Books that day in 2003, it was the one that seemed to be the
>> most clear and informative.
>
> The most important thing I would want from a Verilog book wasn't
> mentioned in your list of features of a good Verilog book, a description
> of the pitfalls of the Verilog language.  The issues you cover are all
> language independent in my opinion.  I once asked specifically about
> finding a book to cover the pitfalls and was told that none existed.  I
> asked again a year or two ago and was told the same thing.
>

A decent reference for this is Sutherland and Mills "Verilog and
SystemVerilog Gotchas".

Regards,
Chris


Article: 156990
Subject: Re: LVDS problem - Black magic anyone?
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 13 Aug 2014 16:02:24 -0500
Links: << >>  << T >>  << A >>
thomas.entner99@gmail.com wrote:


> The cable is a "flat Ethernet cable" with 4 twisted pairs, one pair is
> unused, one pair is LVDS, one pair is GND + Rxd and the last is Power +
> TxD.
This is NOT LVDS!  The D stands for Differential!  You use one wire of the
pair for the true signal, one wire for the complement signal.  I don't even
know how you do single-ended with LVDS receivers, but it won't work well,
as you clearly have discovered.

You can still use LVDS the right way with 3 pairs.  One pair is power &
ground, one is the Rxd true/compl pair, the other is the Txd true/compl
pair.

Jon

Article: 156991
Subject: Re: LVDS problem - Black magic anyone?
From: langwadt@fonz.dk
Date: Wed, 13 Aug 2014 14:59:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den onsdag den 13. august 2014 23.02.24 UTC+2 skrev Jon Elson:
> thomas.entner99@gmail.com wrote:
> 
> 
> 
> 
> 
> > The cable is a "flat Ethernet cable" with 4 twisted pairs, one pair is
> 
> > unused, one pair is LVDS, one pair is GND + Rxd and the last is Power +
> 
> > TxD.
> 
> This is NOT LVDS!  The D stands for Differential!  You use one wire of the
> 
> pair for the true signal, one wire for the complement signal.  I don't even
> 
> know how you do single-ended with LVDS receivers, but it won't work well,
> 
> as you clearly have discovered.
> 
> 
> 
> You can still use LVDS the right way with 3 pairs.  One pair is power &
> 
> ground, one is the Rxd true/compl pair, the other is the Txd true/compl
> 
> pair.
> 

afaiu, he is using one pair for LDVS, the other rx/tx is single ended uart
paired with gnd and power. So the wiring is ok 

-Lasse


Article: 156992
Subject: Re: LVDS problem - Black magic anyone?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 13 Aug 2014 23:07:32 +0100 (BST)
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> wrote:
> This is NOT LVDS!  The D stands for Differential!  You use one wire of the
> pair for the true signal, one wire for the complement signal.  I don't even
> know how you do single-ended with LVDS receivers, but it won't work well,
> as you clearly have discovered.
> 
> You can still use LVDS the right way with 3 pairs.  One pair is power &
> ground, one is the Rxd true/compl pair, the other is the Txd true/compl
> pair.

The OP stated he has one LVDS pair (D+ and D- twisted), and two UART signals
(RXD and TXD).  The UART signals aren't sent by LVDS, they're just other
things down the same cable.  I assume the OP's LVDS is unidirectional (or
else there would be other issues).  The OP's situation of having RXD+GND and
TXD+VCC pairs, rather than RXD+TXD and GND+VCC, is probably slightly better
but it's marginal at typical UART speeds (and as always depends on the setup
- as we've discovered the 'twisted pair' isn't).

You can connect single-ended into an LVDS receiver by grounding the negative
input (if you have positive and negative voltage rails) or putting it
mid-range via a resistive divider (on a single supply arrangement) but
you've just halved your signal amplitude (and thus differential SNR) - and
of course you have no protection from common-mode noise.

Theo

Article: 156993
Subject: Re: Has anyone forked any Xilinx IP?
From: sp@orbitalfox.com (SP)
Date: Thu, 14 Aug 2014 14:25:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mark Curry <gtwrek@sonic.net> wrote:
> We've had to do it.  The general rule is to quickly throw away any use
> of Xilinx's "wizards" or other hold-your-hand GUIs.  Get to the 
> straight RTL and just use that.  Most of Xilinx's current 
> IP is unencrypted RTL - although buried deep within wrappers
> and other "wizardly" cruft.

Seems a good advice if one is headed towards in-depth understanding of
the IP they are using. But what about situations where this is not
needed?

Personally I tend to want to be in the fist group, but I am curious for
the other reasons.

I take it you didn't throw away the tcl templates?

> Now, it's simple. Just edit the RTL as needed and continue.

This is the juicy part -- where? How do you re-include these in the rest
of the design? What about keeping it flexible and future proof?

-- 
    Stavros

Article: 156994
Subject: Re: Has anyone forked any Xilinx IP?
From: gtwrek@sonic.net (Mark Curry)
Date: Thu, 14 Aug 2014 16:58:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <lsigti$lvp$1@dont-email.me>, SP <sp@orbitalfox.com> wrote:
>Mark Curry <gtwrek@sonic.net> wrote:
>> We've had to do it.  The general rule is to quickly throw away any use
>> of Xilinx's "wizards" or other hold-your-hand GUIs.  Get to the 
>> straight RTL and just use that.  Most of Xilinx's current 
>> IP is unencrypted RTL - although buried deep within wrappers
>> and other "wizardly" cruft.
>
>Seems a good advice if one is headed towards in-depth understanding of
>the IP they are using. But what about situations where this is not
>needed?

We only edit Xilinx IP when we're forced to.  One case, was to fix a bug
that we just couldn't convince them was indeed a bug.   It was just easier
to fix it ourselves.

For another it was to add features that were not present. 

>Personally I tend to want to be in the fist group, but I am curious for
>the other reasons.
>
>I take it you didn't throw away the tcl templates?

"tcl templates"?

Don't even know what you're referring to here.  Perhaps something in Vivado?
Either way, we don't use tcl templates.  We run vivado in non-project mode
with our own tcl scripts.

>> Now, it's simple. Just edit the RTL as needed and continue.
>
>This is the juicy part -- where? How do you re-include these in the rest
>of the design? What about keeping it flexible and future proof?

We copy over all IP into our revision control repository (regardless of
whether we're editting it or not).  This future proofs it against random 
updates from the vendor (oh pcore version x.x.x is no longer supported/
available by tool z.z.z...)  RTL is RTL.

Regards,

Mark


Article: 156995
Subject: Re: LVDS problem - Black magic anyone?
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 14 Aug 2014 14:02:37 -0500
Links: << >>  << T >>  << A >>
Theo Markettos wrote:


> The OP stated he has one LVDS pair (D+ and D- twisted), and two UART
> signals
> (RXD and TXD).  The UART signals aren't sent by LVDS, they're just other
> things down the same cable.
OK, he confused  me with the UART data signals.

Well, one other thing, is he terminating the LVDS with a resistor matching
the characteristic impedance of the cable?  I'll bet he isn't, his results
would VERY likely match what he describes.  We use 100 Ohm resistors, they
are close enough.  For best results, tune between 110 and 120 Ohms for
minimum reflection.

Jon


Article: 156996
Subject: Re: LVDS problem - Black magic anyone?
From: alb <alessandro.basili@cern.ch>
Date: Thu, 14 Aug 2014 23:17:54 +0200 (CEST)
Links: << >>  << T >>  << A >>
hi Jon,

Jon Elson <jmelson@wustl.edu> Wrote in message:
> Well, one other thing, is he terminating the LVDS with a resistor matching
> the characteristic impedance of the cable?  I'll bet he isn't, his results
> would VERY likely match what he describes.  We use 100 Ohm resistors, they
> are close enough.  For best results, tune between 110 and 120 Ohms for
> minimum reflection.

from the OP:
 I tried changing and even removing the termination resistors,
 this did not change the behavior at all. I have changed both
 boards, it is really the cable that makes the difference.

BTW, removing the terminators on an LVDS - single drop - line is
 *never* a good idea. LVDS drivers are current sources and the
 receiver may simply not tolerate the differential swing on it's
 big  input impedance.

I did not understand how the op solved his problem changing
 receiver equalization, he clearly mentioned some cables did work
 ok without the need to change equalization...

Al

Article: 156997
Subject: Re: LVDS problem - Black magic anyone?
From: thomas.entner99@gmail.com
Date: Thu, 14 Aug 2014 14:54:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
Wow, quite some discussion going on here... (I have considered this myself =
"solved" and working on other stuff again.)

To give some comments:
Yes, we use 100 ohm termination, in fact on both sides of the cable. I trie=
d to remove the termination on both sides (but I don't think I have removed=
 both sides at the same time - would not really make sense...). I have also=
 checked with a multimeter and got the correct values (e.g. 50 ohm, when bo=
th are mounted and cable connected.)

My conclusion was, that with the original (quite strong) equalizer setting =
things were barely working (even with "good" cables I got an transmission e=
rror here and then while "bad" cables resulted in errors all over). I think=
 it was simply to strong for the short cable distance. With the lowest poss=
ible equalizer setting we have not seen any transmission errors anymore wit=
h any combination of boards and cables.

I had dismantled one cable and found that the (while they were really twist=
ed) the turn rate was very low, about 1 to 2 full turns about the complete =
length. This might be good enough for long ethernet cables, but I can imagi=
ne that this  short length make some of them almost behave like untwisted c=
ables with quite some cross talk. This is my explanation why touching the u=
ntwisted wires had some influence although I am still surprised that the ef=
fect was such a drastic improvement.

What I still cannot understand is why the (in my opinion) much more dramati=
c change of removing the termination resistors had no influence (not good n=
or bad) on this obviously barely working system while the touching had.

Regards,

Thomas

Article: 156998
Subject: Re: LVDS problem - Black magic anyone?
From: al.basili@gmail.com (alb)
Date: 17 Aug 2014 16:57:33 GMT
Links: << >>  << T >>  << A >>
Hi Thomas,

thomas.entner99@gmail.com wrote:
[]
> To give some comments: Yes, we use 100 ohm termination, in fact on both 
> sides of the cable. I tried to remove the termination on both sides (but I 
> don't think I have removed both sides at the same time - would not really 
> make sense...). I have also checked with a multimeter and got the correct 
> values (e.g. 50 ohm, when both are mounted and cable connected.)

I do not understand why you need termination at both ends. There are two 
aspects when terminating an LVDS line:

1. line impedence matching.
2. provide a load for a current source.

In both cases it does not make too much sense to have a termination at the 
source.

> My conclusion was, that with the original (quite strong) equalizer setting 
> things were barely working (even with "good" cables I got an transmission 
> error here and then while "bad" cables resulted in errors all over). I think 
> it was simply to strong for the short cable distance. With the lowest 
> possible equalizer setting we have not seen any transmission errors anymore 
> with any combination of boards and cables.

Did you see your signal on the scope *after* the receiver for both a /good/ 
and /bad/ cable? Do you have an eye diagram?

> 
> I had dismantled one cable and found that the (while they were really 
> twisted) the turn rate was very low, about 1 to 2 full turns about the 
> complete length. This might be good enough for long ethernet cables, but I 
> can imagine that this short length make some of them almost behave like 
> untwisted cables with quite some cross talk. 

twist per meter is usually specified in the cable datasheet; considering the 
rate you're working at I'd seriously consider the cable as a fundamental part 
to be analyzed.

> This is my explanation why 
> touching the untwisted wires had some influence although I am still 
> surprised that the effect was such a drastic improvement.

I would not call 'improvement' something that you cannot justify or explain. 
Since you do not know what is going on, it is *very* possible the problem is 
simply hidden for a various combination of causes and will likely reappear 
later on.

> What I still cannot understand is why the (in my opinion) much more dramatic 
> change of removing the termination resistors had no influence (not good nor 
> bad) on this obviously barely working system while the touching had.

IMO your connection is far from being a proper one, with serious matching 
issues and a very scattered amount of information to analyze. With these basis 
any conclusion on 'working' or 'not working' are pointless at best.

If you don't have a model to explain why it works and why it doesn't, your 
likely exposed to see the issue again later and thanks to Murphy's law it 
would be right two days before shipping!

If you want to seriously remove your issues you need to be able to explain 
every detail, spot the cause and remove it. Otherwise it would just be another 
piece of guesswork.

Al

Article: 156999
Subject: Re: LVDS problem - Black magic anyone?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 17 Aug 2014 19:02:26 +0100
Links: << >>  << T >>  << A >>
On 17/08/14 17:57, alb wrote:
> Hi Thomas,
>
> thomas.entner99@gmail.com wrote:
> []
>> To give some comments: Yes, we use 100 ohm termination, in fact on both
>> sides of the cable. I tried to remove the termination on both sides (but I
>> don't think I have removed both sides at the same time - would not really
>> make sense...). I have also checked with a multimeter and got the correct
>> values (e.g. 50 ohm, when both are mounted and cable connected.)
>
> I do not understand why you need termination at both ends. There are two
> aspects when terminating an LVDS line:
>
> 1. line impedence matching.
> 2. provide a load for a current source.
>
> In both cases it does not make too much sense to have a termination at the
> source.

See "LVDS Owner's Manual Design Guide , 4th Edition"
http://www.ti.com/lit/ml/snla187/snla187.pdf


> Did you see your signal on the scope *after* the receiver for both a /good/
> and /bad/ cable? Do you have an eye diagram?

Ensure the probes don't disturb the signal - which is easier said
than done.






Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search