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 156950

Article: 156950
Subject: Re: Could you give me an example on synthesis techniques?
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 02 Aug 2014 08:58:50 -0500
Links: << >>  << T >>  << A >>
That sentence muddles up a few things.
I wouldn't spend too much time with the paper in question.

First, optimization is by definition not supposed to change the
functionality. If it does, it means my code didn't completely capture the
desired functionality. So this emphasizes the importance of writing correct
code ...

What can happen is much more subtle than just "deleting connections". 
For example, off-chip signals are fairly sensitive to the way they are
implemented (digital hazards by combinational logic), many things can go
wrong if the implementation is sloppily done.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156951
Subject: Re: Could you give me an example on synthesis techniques?
From: rickman <gnuarm@gmail.com>
Date: Sat, 02 Aug 2014 12:11:00 -0400
Links: << >>  << T >>  << A >>
On 8/2/2014 6:49 AM, fl wrote:
> Hi,
> I read a paper on FPGA design. It has the following statements:
>
>
>
> "Successfully simulated programs might not work on device
> because synthesizer tries to optimize design and it can delete
> some connections which affect result. Hence a good knowledge of
> synthesizer is of importance in FPGA program development."
>
>
> I have done some small and medium FPGA projects, but never experience
> surprising synthesis result as the above statement. Could you give me
> an example to show the XST synthesis control to turn a failure to success?

By "optimization" they mean logic that is not used to produce an 
internal state signal or an output from the device can be trimmed away. 
  There is no reason to implement logic if it has no impact on the 
function of the chip.  This is also true of logic that has no driver on 
an input, but I believe you get errors when that happens.

I don't understand your question about synthesis turning a "failure to 
success"....  That simply won't happen.

-- 

Rick

Article: 156952
Subject: Re: Could you give me an example on synthesis techniques?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 3 Aug 2014 04:29:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
fl <rxjwg98@gmail.com> wrote:

> I read a paper on FPGA design. It has the following statements:
 
> "Successfully simulated programs might not work on device
> because synthesizer tries to optimize design and it can delete
> some connections which affect result. Hence a good knowledge of 
> synthesizer is of importance in FPGA program development."

Proper synchronous logic should simulate and synthesize properly.
If you do post route timing, you should satisfy the timing requirements,
or, you should find the speed at which your design can run.

Designs should not, for example, rely on delays. I believe that it
is usual for synthesis to ignore any delays specified, but the
simulation will handle them. Just don't do it, except for simulation
fixtures, like generating clocks for simulation.
 
> I have done some small and medium FPGA projects, but never experience
> surprising synthesis result as the above statement. Could you give me
> an example to show the XST synthesis control to turn a failure 
> to success?

If logic is removed, it should give a warning message, and you should
probably agree with the message.

-- glen

Article: 156953
Subject: Re: floating point synthesis on Xilinx FPGAs using ISE Webpack
From: Thorsten Kiefer <thorstenkfr@googlemail.com>
Date: Mon, 4 Aug 2014 03:47:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Freitag, 1. August 2014 18:06:30 UTC+2 schrieb vicash:
> Hi
>=20
>=20
>=20
> I have been researching floating and/or fixed point support for Xilinx FP=
GAs that can be synthesized using the ISE Webpack toolkit. After foolishly =
trying to synthesize the "real" type and then researching various options I=
 came across the following links:
>=20
>=20
>=20
>     http://www.eda-stds.org/fphdl/
>=20
>=20
>=20
>     http://www.vhdl.org/fphdl/vhdl.html
>=20
>=20
>=20
> Now, I am a little confused as to how to go about using these sources. Th=
ey mention using the IEEE_proposed library.
>=20
>=20
>=20
> Q. Does that mean that Xilinx ISE will provide the IEEE_proposed library =
?
>=20
>=20
>=20
> Q. If not, do I have to compile this library myself using the provided so=
urce code for fixed and floating point math ?
>=20
>=20
>=20
> Q. Has anyone successfully used this code and/or synthesized floating poi=
nt on a Xilinx FPGA using ISE Webpack ?
>=20
>=20
>=20
> Any help will be appreciated.
>=20
>=20
>=20
> Thanks
>=20
> vicash

Did you try out Xilinx's floating point IP-Cores ?

Regards
Thorsten

Article: 156954
Subject: Re: Microprocessor architecture (6800, 4004? PA-RISC, PPC, MIPS, x86, ...?)
From: johngreer2003@yahoo.com
Date: Mon, 4 Aug 2014 17:37:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
 Honey Sue Elovitz..................my in class instructor in 1970 at University of Maryland Fortran V class!!!!!

Article: 156955
Subject: How can Spartan-6 interface with 10/100 Mb/s Ethernet?
From: fl <rxjwg98@gmail.com>
Date: Tue, 5 Aug 2014 05:49:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I read LogiCORE IP AXI Ethernet Lite MAC (v1.01.b), which says that the Ethernet 
interface is with 10Mb/s 100Mb/s. On its spec, I find that the maximum clock for
Spartan xc6slx45t AXI4-lite 120 MHz (Target Fmax). I am puzzled about the two
categories numbers. 120 MHz is only marginal higher than 100 Mb/s. How can it 
recover a 100 Mb/s data?
Could you explain it to me? Thanks,

Article: 156956
Subject: Re: How can Spartan-6 interface with 10/100 Mb/s Ethernet?
From: Russell <russellmerrick@gmail.com>
Date: Tue, 5 Aug 2014 06:35:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
Consider what happens when you go from a serial interface (like in Ethernet=
) to a parallel interface.  If you have a 1 bit wide interface at 100 Mb/s =
interfacing to a 16 bit wide parallel interface, your parallel interface on=
ly needs to run at 6.25 Mb/s (100/16).  As long as the module that does the=
 serial to parallel conversion can keep up, the rest of the logic can run i=
n parallel and can be run much slower.

On Tuesday, August 5, 2014 8:49:47 AM UTC-4, fl wrote:
> Hi,
>=20
> I read LogiCORE IP AXI Ethernet Lite MAC (v1.01.b), which says that the E=
thernet=20
>=20
> interface is with 10Mb/s 100Mb/s. On its spec, I find that the maximum cl=
ock for
>=20
> Spartan xc6slx45t AXI4-lite 120 MHz (Target Fmax). I am puzzled about the=
 two
>=20
> categories numbers. 120 MHz is only marginal higher than 100 Mb/s. How ca=
n it=20
>=20
> recover a 100 Mb/s data?
>=20
> Could you explain it to me? Thanks,


Article: 156957
Subject: Re: How can Spartan-6 interface with 10/100 Mb/s Ethernet?
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 05 Aug 2014 09:46:00 -0400
Links: << >>  << T >>  << A >>
fl wrote:
> Hi,
> I read LogiCORE IP AXI Ethernet Lite MAC (v1.01.b), which says that the Ethernet 
> interface is with 10Mb/s 100Mb/s. On its spec, I find that the maximum clock for
> Spartan xc6slx45t AXI4-lite 120 MHz (Target Fmax). I am puzzled about the two
> categories numbers. 120 MHz is only marginal higher than 100 Mb/s. How can it 
> recover a 100 Mb/s data?
> Could you explain it to me? Thanks,

The PHY interface (MII) runs at 25 MHz for a 100 Mbps link.  The AXI bus
is much wider than even that interface, so it can easily deal with 1Gpbs
Ethernet.  Note that the 120 MHz limit is at the AXI interface and not
the I/O side of the module.

-- 
Gabor

Article: 156958
Subject: strange effect with tristate output
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 07 Aug 2014 19:35:15 +0200
Links: << >>  << T >>  << A >>
I'm using a XC95144XL, two pins are an input for a 5V signal, which have
pullup resistors (3k3). Setting the pins to low from my VHDL design
works great. Then I thought I could set it to high, too, to avoid the
latency of the pullup resistor. But as soon as I switch it back to input
(pin <= 'Z'), the voltage drops again, as if it switches to some capacitor:

http://i.imgur.com/EYV05oS.png

and only then the pullup resistor starts charging the parasitic
capacitance. I don't understand this behaviour, because the parasitic
capacitance should be already charged when switching.

Maybe something different is wrong in my circuit, I'll try to implement
some independant test case, but maybe someone knows already what is
going on or how I could fix it.

-- 
Frank Buss, http://www.frank-buss.de
C64 MIDI interface, preorder: http://www.frank-buss.de/c64/midi/buy.html

Article: 156959
Subject: Re: strange effect with tristate output
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 07 Aug 2014 13:03:12 -0500
Links: << >>  << T >>  << A >>
In article <ls0dck$v9p$1@newsreader4.netcologne.de>,
 Frank Buss <fb@frank-buss.de> writes:
>I'm using a XC95144XL, two pins are an input for a 5V signal, which have
>pullup resistors (3k3). Setting the pins to low from my VHDL design
>works great. Then I thought I could set it to high, too, to avoid the
>latency of the pullup resistor. But as soon as I switch it back to input
>(pin <= 'Z'), the voltage drops again, as if it switches to some capacitor:
>
>http://i.imgur.com/EYV05oS.png
>
>and only then the pullup resistor starts charging the parasitic
>capacitance. I don't understand this behaviour, because the parasitic
>capacitance should be already charged when switching.
>
>Maybe something different is wrong in my circuit, I'll try to implement
>some independant test case, but maybe someone knows already what is
>going on or how I could fix it.

My guess is that you are setting the output to low in the same cycle
that you disable the output driver.  That leaves a race between turning
off before, during, or after the output has switched to low.  It looks
like it was during, the output has switched halfway to low.

-- 
These are my opinions.  I hate spam.


Article: 156960
Subject: Re: strange effect with tristate output
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 07 Aug 2014 13:55:40 -0500
Links: << >>  << T >>  << A >>
Frank Buss wrote:

> I'm using a XC95144XL, two pins are an input for a 5V signal,

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.  

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.

Jon

Article: 156961
Subject: Re: strange effect with tristate output
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 07 Aug 2014 23:35:05 +0200
Links: << >>  << T >>  << A >>
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.

-- 
Frank Buss, http://www.frank-buss.de
C64 MIDI interface, preorder: http://www.frank-buss.de/c64/midi/buy.html

Article: 156962
Subject: multicycle path - synplify pro
From: al.basili@gmail.com (alb)
Date: 8 Aug 2014 07:45:35 GMT
Links: << >>  << T >>  << A >>
Hi everyone,

I'm experiencing an issue with Synplify Pro E-2010.09A-1. I have to 
insert some multicycle paths in order to be able to implement the design 
(no option to break the paths with registers because the management has 
decided to not modify the vhdl source at *any* cost...how wise!).

The constraints are:

> create_clock -period 25.0 [get_ports {clk_i}]
> 
> set_multicycle_path 2 -from    [get_cells execute0.fpu0.fpu_op_r*] \
>                       -to      [get_cells execute0.fpu0.REGISTER_o*]
>
> set_multicycle_path 2 -from    [get_cells execute0.fpu0.fpu_op_r*] \
>                       -to      [get_cells execute0.fpu0.result_o*]


Which are well expanded to the following exctract (I spared you with 
some long list of unimportant objects):


> Constraints with matching wildcard expressions
> **********************************************
> 
> set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.REGISTER_o* }
> 	@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
> 		execute0.fpu0.fpu_op_r_i[7]
[skip]
>		execute0.fpu0.fpu_op_r[0:7]
>	@N:|expression "execute0.fpu0.REGISTER_o*" applies to objects:
>		execute0.fpu0.REGISTER_o_192
[skip]
>		execute0.fpu0.REGISTER_o[58:0]
> set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.result_o* }
>	@N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
>		execute0.fpu0.fpu_op_r_i[7]
[skip]
>		execute0.fpu0.fpu_op_r[0:7]
>	@N:|expression "execute0.fpu0.result_o*" applies to objects:
>		execute0.fpu0.result_o[31:0]

But when I run the synthesis I get the following timing report (worst 
path information):

> Path information for path number 1: 
>       Requested Period:                      25.000
>     - Setup time:                            0.184
>     + Clock delay at ending point:           0.000 (ideal)
>     = Required time:                         24.816
>
>     - Propagation time:                      41.571
>     - Clock delay at starting point:         0.000 (ideal)
>     = Slack (critical) :                     -16.755
> 
>     Number of logic level(s):                72
>     Starting point:                          execute0.fpu0.alu_op_r[0] / q
>     Ending point:                            execute0.fpu0.REGISTER_o[58] / d
>     The start point is clocked by            clk_i [rising] on pin clk
>     The end   point is clocked by            clk_i [rising] on pin clk

Now, why the 'requested period' is set to 25.000 ns it is a mistery to 
me. The starting and ending points should be well identified as covered 
by my multicycle constraint (at least from the constraint check report 
above).

Nevertheless the synthesis tool tries to run it as if there were no 
multicycle paths constraints... Any idea? Shall I file a bug report or 
try with another tool (we have also Precision RTL available)?

Needless to say that I verified in the *.srr file that the constraint 
file *is* taken into account:

[sorry for exceeding 80 chars!]
> Reading constraint file: /home/debian/repos/9123_FOCS_ITA/branches/multicycle-study/mbfocs/target/rtax1000s352_1/synthesis/../synthesis/constraints.sdc
> Adding property syn_multicycle_path1002, value "2.000000 delay from i:execute0.fpu0.fpu_op_r* to i:execute0.fpu0.REGISTER_o*" to view:mblite.core(arch)
> Adding property syn_multicycle_path1003, value "2.000000 delay from i:execute0.fpu0.fpu_op_r* to i:execute0.fpu0.result_o*" to view:mblite.core(arch)


Thanks a lot,

Al

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

Article: 156963
Subject: Re: multicycle path - synplify pro
From: al.basili@gmail.com (alb)
Date: 8 Aug 2014 09:04:02 GMT
Links: << >>  << T >>  << A >>
Hi again,

alb <al.basili@gmail.com> wrote:
[]
>> Constraints with matching wildcard expressions
>> **********************************************
>> 
>> set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.REGISTER_o* }
>>       @N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
>>               execute0.fpu0.fpu_op_r_i[7]
> [skip]
>>               execute0.fpu0.fpu_op_r[0:7]
>>       @N:|expression "execute0.fpu0.REGISTER_o*" applies to objects:
>>               execute0.fpu0.REGISTER_o_192
> [skip]
>>               execute0.fpu0.REGISTER_o[58:0]
>> set_multicycle_path { 2 } -from { i:execute0.fpu0.fpu_op_r* } -to { i:execute0.fpu0.result_o* }
>>       @N:|expression "execute0.fpu0.fpu_op_r*" applies to objects:
>>               execute0.fpu0.fpu_op_r_i[7]
> [skip]
>>               execute0.fpu0.fpu_op_r[0:7]
>>       @N:|expression "execute0.fpu0.result_o*" applies to objects:
>>               execute0.fpu0.result_o[31:0]

I just found that if I specify the constraint taking into account the 
specific register reported by the worst case:

> set_multicycle_path 2 -from    [get_cells execute0.fpu0.fpu_op_r\[4\]] \
>                       -to      [get_cells execute0.fpu0.REGISTER_o\[58\]] 

then it works. The problem is that I need to run the synthesis for each 
multicycle path, while I'd like to provide all the paths concerning a 
set of starting points and a set of ending points directly.

From the Design Constraints User Guide (Actel) it looks like I can 
create indeed a list of starting points:

> set_multicycle_path ncycles [-setup] [-hold] [-from from_list] 
> [­-through through_list] [-to to_list]

But I have failed to understand how a list can be described.
Any ideas or references I can look at?

Al

Article: 156964
Subject: Basic question: sequence of execution within FPGAs
From: Bruce Varley
Date: Fri, 08 Aug 2014 17:38:23 +0800
Links: << >>  << T >>  << A >>
Trying to get my head around FPGAs after 40 years of 2GLs. I can't
seem to find a clear exposition of the following, would appreciate if
someone could confirm or clarify the following assumption:

I have the following Verilog code say:

always @ (posedge clk)
	begin
	do 1
	do 2
	do 3
	end

assign outA = wireA & wireB
assign outB = wireC & wireD

always @ (posedgeclk)
	begin
	do 4
	do 5
	end


Is the following correct?

1, 2 and 3 are done (more or less) in a sequential manner, ie. the
result of 1 will be present when 2 is performed. Hence, statement
order is important here.

4 and 5 will be done using their own gate resources, clocked "more or
less" in parallel with 1,2,3. However, presumably assuming any sort of
time alignment between the results of the two always blocks would be
risky at best (explicit synchronisation required).   

For the assign statements, does clocking pay a part, or do these
statements simply run at gate delay speed? Or is the answer
device-dependent?


Article: 156965
Subject: Re: multicycle path - synplify pro
From: al.basili@gmail.com (alb)
Date: 8 Aug 2014 09:57:39 GMT
Links: << >>  << T >>  << A >>
Again it's me... to close this out!

alb <al.basili@gmail.com> wrote:
[]
> The constraints are:
> 
>> create_clock -period 25.0 [get_ports {clk_i}]
>> 
>> set_multicycle_path 2 -from    [get_cells execute0.fpu0.fpu_op_r*] \
>>                       -to      [get_cells execute0.fpu0.REGISTER_o*]
>>
>> set_multicycle_path 2 -from    [get_cells execute0.fpu0.fpu_op_r*] \
>>                       -to      [get_cells execute0.fpu0.result_o*]


>> Path information for path number 1: 
>>       Requested Period:                      25.000
>>     - Setup time:                            0.184
>>     + Clock delay at ending point:           0.000 (ideal)
>>     = Required time:                         24.816
>>
>>     - Propagation time:                      41.571
>>     - Clock delay at starting point:         0.000 (ideal)
>>     = Slack (critical) :                     -16.755
>> 
>>     Number of logic level(s):                72
>>     Starting point:                          execute0.fpu0.alu_op_r[0] / q
>>     Ending point:                            execute0.fpu0.REGISTER_o[58] / d
>>     The start point is clocked by            clk_i [rising] on pin clk
>>     The end   point is clocked by            clk_i [rising] on pin clk
> 
> Now, why the 'requested period' is set to 25.000 ns it is a mistery to 
> me. The starting and ending points should be well identified as covered 
> by my multicycle constraint (at least from the constraint check report 
> above).

If I read more carefully the name I would have immediately found that:

execute0.fpu0.alu_op_r != execute0.fpu0.fpu_op_r
              ^^^                       ^^^

Sorry for cluttering the group!

Article: 156966
Subject: What is the content of "High-speed SERDES interfacing such as PCIe,
From: fl <rxjwg98@gmail.com>
Date: Fri, 8 Aug 2014 04:33:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I read a job post which requires:

High-speed SERDES interfacing such as PCIe, SDI, SGMII, XAUI


I know FPGA vendors have PCIe IP interfaces. What is the job content with the 
above statements? It requires the engineer to design a PCIe, SDI, SGMII and XAUI
interfaces in house? Or it can accept to use third party IP?

Thanks for explain it to me.

Article: 156967
Subject: Re: Basic question: sequence of execution within FPGAs
From: "mnentwig" <24789@embeddedrelated>
Date: Fri, 08 Aug 2014 07:09:14 -0500
Links: << >>  << T >>  << A >>
Hi,

you may want to get a modern textbook on synchronous logic. With FPGAs, the
design needs to follow a certain pattern, or things get much more difficult
than they need to be.

In Verilog, don't think of a sequence of statements as ordered in time.
Everything happens concurrently. 
Sometimes the order of statements sets a priority, in a sense that the last
assignment holds.

Here is an example for later statements overruling earlier ones. This isn't
directly related to your example, maybe it is useful, maybe not. 
The code works on a Spartan 6 at 100 MHz.

This...

   always @(posedge i_clk) begin      
      //*****************************************************************
      // default: external bus access, confirmed by o_ack
      //*****************************************************************
      db_addrA		<= i_addr;
      db_dataWA		<= i_data;
      db_weA 		<= i_we;
      o_ack 		<= 1'b1;

assigns input from an external bus source (i_addr, i_data, i_we) to
registers that access a memory internal to this subsystem.

Later during the same block, when moon and stars are in the right
constellation, the unit decides to do its own memory access during the same
cycle, and executes this:

if (... certain conditions apply)
      // reads from data memory
      db_addrA		<= addr;
      // take priority over any external memory access attempt
      db_weA 		<= 1'b0;
      o_ack 		<= 1'b0;

What happens is that any earlier assignment is overruled: A different
address is set, different data, and the write_enable flag is changed as
needed. In this example, "o_ack" gets cleared to tell the outside world
"your bus access attempt was ignored - try again"

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156968
Subject: Re: Basic question: sequence of execution within FPGAs
From: Allan Herriman <allanherriman@hotmail.com>
Date: 08 Aug 2014 12:34:42 GMT
Links: << >>  << T >>  << A >>
On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

> Trying to get my head around FPGAs after 40 years of 2GLs. I can't seem
> to find a clear exposition of the following, would appreciate if someone
> could confirm or clarify the following assumption:
> 
> I have the following Verilog code say:
> 
> always @ (posedge clk)
> 	begin do 1 do 2 do 3 end
> 
> assign outA = wireA & wireB assign outB = wireC & wireD
> 
> always @ (posedgeclk)
> 	begin do 4 do 5 end
> 
> 
> Is the following correct?
> 
> 1, 2 and 3 are done (more or less) in a sequential manner, ie. the
> result of 1 will be present when 2 is performed. Hence, statement order
> is important here.

No.  Presumably 1, 2 and 3 involve non-blocking assignments (i.e. using 
<= ) to regs and the statement order isn't important.

I assume your code looks something like this:

always @(posedge clk)
begin
  reg1 <= (some logic);
  reg2 <= (some logic);
  reg3 <= (some logic);
end


Most coding guides will tell you to only using non-blocking assignments 
inside a clocked "always block".

*Very* roughly, these work in simulation by not updating the destination 
reg until all the statements have been executed in all the always blocks 
sensitive to that clock edge.
That simulation behaviour matches flip flop functionality in hardware.

Note that the following two code fragments are equivalent, both in terms 
of simulation behaviour and the hardware described, despite one having 
the statements in reverse order:

always @(posedge clk)
begin
  reg1 <= (some logic);
  reg2 <= reg1;
  reg3 <= reg2;
end

always @(posedge clk)
begin
  reg3 <= reg2;
  reg2 <= reg1;
  reg1 <= (some logic);
end

At each clock,
reg1 gets the value of (some logic) from before the clock edge.
reg2 gets the value of reg1 from before the clock edge.
reg3 gets the value of reg2 from before the clock edge.

[Switch to fixed point font for the ASCII art]

Here are the three flip flops inferred by those code fragments:

clk--------+------------+------------+
           |            |            |
        +-----+      +-----+      +-----+
        |  C  |      |  C  |      |  C  |
some    |     | reg1 |     | reg2 |     | reg3
logic-->|D   Q|----->|D   Q|----->|D   Q|---->
        |     |      |     |      |     |
        |     |      |     |      |     |
        +-----+      +-----+      +-----+


Blocking assignments (using = ) to regs behave roughly like software 
variables and you can have races between always statements.  Don't do 
that, even though it will seem more familiar to you with your software 
background.  You aren't writing software - you are modelling hardware 
using a hardware description language (HDL).  Make sure you think in 
terms of hardware, not software.
 
> 4 and 5 will be done using their own gate resources, clocked "more or
> less" in parallel with 1,2,3.

No.  Assuming you have used non-blocking statements, 1, 2, 3, 4 and 5 all 
infer flip flops clocked by the same clock signal.  Logic resources will 
be allocated / shared / replicated / optimised at the synthesiser's whim 
and this is not necessarily influenced by grouping (or even hierarchy) in 
your source code, unless you have explicitly told the synthesiser not to 
share (perhaps with an attribute).

You should group them so that it makes the code easier to understand and 
maintain.

> However, presumably assuming any sort of
> time alignment between the results of the two always blocks would be
> risky at best (explicit synchronisation required).

Again, if using non-blocking assignments, you can ignore execution order.
 
> For the assign statements, does clocking pay a part, or do these
> statements simply run at gate delay speed? Or is the answer
> device-dependent?

They describe combinatorial logic.  No clock is involved.
In hardware, two AND gates are generated. The actual delay you get will 
be determined by ... well, it's probably more determined by the routing 
than the actual gates (which are pretty fast in contemporary devices).  
You can control the delay by applying timing constraints in the tools.  
In most cases you won't do this as the output of the combinatorial logic 
is simply feeding another flip flop, and the timing constraint you gave 
for the minimum clock period takes care of all paths (including the 
combinatorial logic) between flip flops clocked by that clock.

I hope this helps.

[I apologise if some of my descriptions don't use the correct terminology 
wrt the Verilog LRM.  I'm just trying to explain the gist of the thing.]

Allan

Article: 156969
Subject: Re: Basic question: sequence of execution within FPGAs
From: Tim Wescott <tim@seemywebsite.please>
Date: Fri, 08 Aug 2014 11:09:50 -0500
Links: << >>  << T >>  << A >>
On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

> Trying to get my head around FPGAs after 40 years of 2GLs. I can't seem
> to find a clear exposition of the following, would appreciate if someone
> could confirm or clarify the following assumption:
> 
> I have the following Verilog code say:
> 
> always @ (posedge clk)
> 	begin do 1 do 2 do 3 end
> 
> assign outA = wireA & wireB assign outB = wireC & wireD
> 
> always @ (posedgeclk)
> 	begin do 4 do 5 end
> 
> 
> Is the following correct?
> 
> 1, 2 and 3 are done (more or less) in a sequential manner, ie. the
> result of 1 will be present when 2 is performed. Hence, statement order
> is important here.
> 
> 4 and 5 will be done using their own gate resources, clocked "more or
> less" in parallel with 1,2,3. However, presumably assuming any sort of
> time alignment between the results of the two always blocks would be
> risky at best (explicit synchronisation required).
> 
> For the assign statements, does clocking pay a part, or do these
> statements simply run at gate delay speed? Or is the answer
> device-dependent?

Hey Bruce:

This is just a supplement to what Allan and Mark have said:

You are NOT writing software.  The reason it's called a hardware 
description language is because it does just that -- it describes the 
structure of some hardware.  It's up to you to make sure that the 
structure thus described behaves the way you want it to.

This isn't easy for a seasoned software engineer to wrap their heads 
around -- I have trouble with it whenever I go visiting FPGA-land, in 
spite of the fact that I have no such trouble when I'm designing analog 
circuits with schematics.

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.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 156970
Subject: Re: What is the content of "High-speed SERDES interfacing such as
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 8 Aug 2014 15:11:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, August 8, 2014 4:33:32 AM UTC-7, fl wrote:
> Hi,
>=20
> I read a job post which requires:
>=20
>=20
>=20
> High-speed SERDES interfacing such as PCIe, SDI, SGMII, XAUI
>=20
>=20
>=20
>=20
>=20
> I know FPGA vendors have PCIe IP interfaces. What is the job content with=
 the=20
>=20
> above statements? It requires the engineer to design a PCIe, SDI, SGMII a=
nd XAUI
>=20
> interfaces in house? Or it can accept to use third party IP?
>=20
>=20
>=20
> Thanks for explain it to me.

This is probably a case of "if you have to ask you don't have the experienc=
e". =20

Using the question as a search term in Google turns up a job posting for Cr=
eston looking for people with Xilinx or Altera experience as the first bull=
et item, so this likely means that you have actual experience use the MGT, =
Multi-Gigabit Transceivers, in a real world project implementing one or mor=
e of the listed protocols.

Ed McGettigan
--
Xilinx Inc.   

Article: 156971
Subject: Re: Basic question: sequence of execution within FPGAs
From: Bruce Varley
Date: Sat, 09 Aug 2014 16:05:41 +0800
Links: << >>  << T >>  << A >>
On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

>Trying to get my head around FPGAs after 40 years of 2GLs. I can't
>seem to find a clear exposition of the following, would appreciate if
>someone could confirm or clarify the following assumption:
>
>I have the following Verilog code say:
>
>always @ (posedge clk)
>	begin
>	do 1
>	do 2
>	do 3
>	end
>
>assign outA = wireA & wireB
>assign outB = wireC & wireD
>
>always @ (posedgeclk)
>	begin
>	do 4
>	do 5
>	end
>
>
>Is the following correct?
>
>1, 2 and 3 are done (more or less) in a sequential manner, ie. the
>result of 1 will be present when 2 is performed. Hence, statement
>order is important here.
>
>4 and 5 will be done using their own gate resources, clocked "more or
>less" in parallel with 1,2,3. However, presumably assuming any sort of
>time alignment between the results of the two always blocks would be
>risky at best (explicit synchronisation required).   
>
>For the assign statements, does clocking pay a part, or do these
>statements simply run at gate delay speed? Or is the answer
>device-dependent?

Well, I have some work (and some backtracking) to do. Many thanks for
the good info, folks. 

Article: 156972
Subject: LVDS problem - Black magic anyone?
From: thomas.entner99@gmail.com
Date: Sat, 9 Aug 2014 11:57:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. On=
ly 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 unus=
ed, one pair is LVDS, one pair is GND + Rxd and the last is Power + TxD.

Most cables work fine with a low error rate. However, some cables of the sa=
me batch have an excessive error rate. These cables have no visible differe=
nce to the good cables.

The end of the cables have the outer isolation removed for about 5cm, the L=
VDS pair is twisted also for this 5cm, the other wires are straight crimped=
 to the connector.

Now the strange behavior: When touching the cable at some positions by hand=
, the bad cables are suddenly perfect or at least much better. And the even=
 stranger thing: When touching at the last 5cm, it is NOT the touching of t=
he LVDS pair that makes the difference, but the touching the GND/Power/Uart=
 wires! This can be observed on both sides of the cable.

It is really only "the hand" that makes the difference, strapping together =
the wires does not help. It does also not look like a mechanical problem of=
 the cable.

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 ca=
ble that makes the difference.

Has anybody an idea what the reason of this behavior could be?

Regards,

Thomas

Article: 156973
Subject: Re: LVDS problem - Black magic anyone?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 09 Aug 2014 23:24:55 +0100 (BST)
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.
> 
> Most cables work fine with a low error rate. However, some cables of the
> same batch have an excessive error rate.  These cables have no visible
> difference to the good cables.

What category cable is it?  Even cat6 or cat6a aren't intended for use
beyond 500MHz.  While there's less loss because the cable is shorter, it's
worth looking up the loss curves and doing the calculation.  You have
checked that the 'flat' cable does actually contain twisted pairs?

What's the position of the ground with respect to the LVDS pair?  Is it
adjacent, or further away?  Are these direct electrical connections, or is
there any signal isolation?  Is the spare pair floating?

What's the grounding arrangements of both boards?  Is this the only ground
connection between them?  How are they powered?  Do they come from the same
AC source, or different sources?  What's the arrangement of earths, and any
possibility they could be on different AC phases?

What are you driving the RXD/TXD signals with?  Do you know their rise time?

For that matter, do you know the rise time of the LVDS signals?
What are you using for an LVDS receiver? (Any equalisation?)
What's the encoding on the wire (8b/10b, Manchester, etc)?

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

Have you looked at the signal on a scope?

Where did the 'termination resistors' come from?  How did you decide what
topology and what values to use?

> Has anybody an idea what the reason of this behavior could be?

Some ideas:
1. You're changing the capacitance of the cable by touching it
2. You're creating a capacitive path to ground through your body
3. You're changing the topology of the inductive loop between an LVDS line
and ground
4. You're coupling other signals into the LVDS pair (eg RXD), especially if
the twists have ended up aligned
5. The signal has higher frequency components than you think and these are
messing up the receiver.  Extra capacitance by touching increases their
loss, enough for the receiver to cope
6. The cable is simply too lossy at the frequency you're using
7. You have a grounding issue with the setup
8. The line isn't terminated correctly so you're getting reflections which
interfere with the signal

Do you have a network analyser available?  Looking at the insertion loss of
the cable over a range of frequencies may tell you something about what's
going on.


I've done a lot of work with SATA cables.  Bottom line is, some are just
cheap and simply don't work.  SATA error recovery is enough to mask many of
the problems when used in a PC, so nobody notices.

Theo

Article: 156974
Subject: Re: LVDS problem - Black magic anyone?
From: thomas.entner99@gmail.com
Date: Sun, 10 Aug 2014 02:12:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
> > I have an LVDS related issue that drives me crazy:
> >=20
> > 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)
> >=20
> > 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.
> >=20
> > Most cables work fine with a low error rate. However, some cables of th=
e
> > same batch have an excessive error rate.  These cables have no visible
> > difference to the good cables.
>=20
>=20
> What category cable is it?

CAT5e (UTP)

> Even cat6 or cat6a aren't intended for use
> beyond 500MHz.  While there's less loss because the cable is shorter, it'=
s
> worth looking up the loss curves and doing the calculation.  You have
> checked that the 'flat' cable does actually contain twisted pairs?

I have opened up a cable now - the pairs are twisted but the turn rate is m=
uch lower than what I would have expected - it is about one full turn every=
 20cm or so.

> What's the position of the ground with respect to the LVDS pair?

Ground is (only) in this cable, it is paired with  RxD:
1st pair: GND + RxD
2nd pair: LVDS
3rd pair: Power + TxD
4th pair: unused

> Is it
> adjacent, or further away?  Are these direct electrical connections, or i=
s
> there any signal isolation?

Ground is only connected through the cable between the board. The transmitt=
er side (a small sensor board) has no other connections to it at all. The r=
eceiver side has other connections like HDMI, etc.

In fact, there is a ferrite bead on the sensor PCB in the ground and in the=
 power path (directly at the connector). But I also have already bridged th=
is beads with zero ohm -> no change.

> Is the spare pair floating?

Yes. I have removed this wires from one bad cable now -> no change.

> What's the grounding arrangements of both boards?  Is this the only groun=
d
> connection between them?=20
See above

> How are they powered?  Do they come from the same
> AC source, or different sources?  What's the arrangement of earths, and a=
ny
> possibility they could be on different AC phases?
The receiving board is powered via an external +12V power supply, the senso=
r board is only powered via this cable.

> What are you driving the RXD/TXD signals with?  Do you know their rise ti=
me?
With 3.3V FPGA I/O pins with series resistors and even some small cap at th=
e connector. The rise-time is very slow. I have also stopped the UART commu=
nciaton for testing -> no change.


> For that matter, do you know the rise time of the LVDS signals?
Unfortunately: No (I have only a 500 MHz scope)

> What are you using for an LVDS receiver? (Any equalisation?)
It is a Cyclone IVGX SerDes. Yes, equalization is active (at a medium setti=
ng). I will play around a little bit with this settings (unfortunately the =
compile-time is quite long).

> What's the encoding on the wire (8b/10b, Manchester, etc)?
It is quite a simple protocol with start- and stop-bit (10b data-word) as u=
sed by DS92LV1023 (no DC balancing)

> > 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 t=
he
> > cable that makes the difference.
> Have you looked at the signal on a scope?
Yes (as good as possible with a 500MHz scope...): I see no visible change i=
n all the signals when touching the cable. Only the dramatic effect in the =
error rate. What surprises me is that the scope probe has almost no influen=
ce on the error rate while the touching by hand does...

> Where did the 'termination resistors' come from?  How did you decide what
> topology and what values to use?
They are 100R on both sides (as this is what I expect as impedance of a CAT=
5e cable). I put a 100R also on the transmitter side as this improves the r=
obustness in my experience, esp. with longer cables. I also removed the 100=
R on the transmitter side and it did not help.

> > Has anybody an idea what the reason of this behavior could be?
> Some ideas:
> 1. You're changing the capacitance of the cable by touching it
> 2. You're creating a capacitive path to ground through your body
> 3. You're changing the topology of the inductive loop between an LVDS lin=
e
> and ground
> 4. You're coupling other signals into the LVDS pair (eg RXD), especially =
if
> the twists have ended up aligned
> 5. The signal has higher frequency components than you think and these ar=
e
> messing up the receiver.  Extra capacitance by touching increases their
> loss, enough for the receiver to cope
> 6. The cable is simply too lossy at the frequency you're using
> 7. You have a grounding issue with the setup
> 8. The line isn't terminated correctly so you're getting reflections whic=
h
> interfere with the signal
I will have to think further about these...

> Do you have a network analyser available?  Looking at the insertion loss =
of
> the cable over a range of frequencies may tell you something about what's
> going on.
Unfortunately: No.

> I've done a lot of work with SATA cables.  Bottom line is, some are just
> cheap and simply don't work.  SATA error recovery is enough to mask many =
of
> the problems when used in a PC, so nobody notices.
>=20
> Theo

Thanks a lot. This discussing this issue with someone really helps. I will =
post new results here when I have any.

Regards,

Thomas



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