Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.comArticle: 156951
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. -- RickArticle: 156952
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. -- glenArticle: 156953
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 ThorstenArticle: 156954
Honey Sue Elovitz..................my in class instructor in 1970 at University of Maryland Fortran V class!!!!!Article: 156955
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
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
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. -- GaborArticle: 156958
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.htmlArticle: 156959
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
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. JonArticle: 156961
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.htmlArticle: 156962
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
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: 156964Trying 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
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: 156966Hi, 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
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
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: 156969On 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.comArticle: 156970
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
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
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, ThomasArticle: 156973
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. TheoArticle: 156974
> > 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:
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