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 129925

Article: 129925
Subject: Re: SiliconBlue enters the FPGA fray
From: austin <austin@xilinx.com>
Date: Mon, 10 Mar 2008 10:35:34 -0700
Links: << >>  << T >>  << A >>
John_H,

Aye, that is the rub:  success.

Austin

Article: 129926
Subject: Re: SiliconBlue enters the FPGA fray
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 10 Mar 2008 10:44:25 -0700 (PDT)
Links: << >>  << T >>  << A >>

> If you consider SiliconBlue to be a younger (newer) PLD company than
> Xilinx, the issue is just one of success.  Antti's point seems to be
> that their tool development wouldn't be hampered by the legacy of any
> successful PLD company that's 20 years or more in age.
>
> I love Xilinx.  And I often fight with arcane tools.  It doesn't
> change the lure of the silicon and raw capabilities.
>
> I appreciate small company mentality, but there's only so much that
> can be done against the history of millions of lines of code.
>
> - John_H

When we say that (almost 25-year-old) Xilinx is the youngest
successful PLD company,
we are looking back on decades of exciting announcements by start-ups
and also big companies getting into this business.
Here is the gist of a slide that I have used for over a year:

"A Maturing Industry...

The two leaders have a combined market share of 86%
leaving 14% for Lattice, Actel, Quicklogic, Atmel...

All broad-based suppliers have given up:
Intel, T.I., AMD, ATT, Philips, Cypress, NSC, Motorola

"FPGAs demand too much management attention"

Most start-ups vanished:
Dynachip, PlusLogic, Triscend, Siliconspice (absorbed)
Chameleon, Quicksilver, Morphics, Adaptive Silicon (failed)

Fab-less might make it easy, but there are strong barriers to entry:
Tool familiarity, design re-use, risk avoidance by the users,
Economy of scale, patents, technical support, availability of sales
channels

Where is the next successful FPGA start-up?"

End of quote.
I do not necessarily expect this situation to last another 20 years,
and it gives us no reason for complacency or arrogance.
But it is a sobering thought whenever listening to the newest
announcements...
Peter Alfke, Xilinx Applications



Article: 129927
Subject: Re: Spartan-3A DSP Starter: JX Connector Part number
From: Bryan <bryan.fletcher@avnet.com>
Date: Mon, 10 Mar 2008 11:07:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 7, 8:25=A0am, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de>
wrote:
> John_H <newsgr...@johnhandwork.com> wrote:
>
> ...
>
> > The mating connector is the QSE-060-01-L-D-A where Digikey also has stoc=
k.
>
> Thanks,
>
> seems I had tomatoes on my eyes...
> --
> Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-darm=
stadt.de
>
> Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

For more information on the EXP expansion system, see www.em.avnet.com/exp

Bryan

Article: 129928
Subject: Re: Virtex-4 VLX25 DCM problem
From: "Grubi" <dkolev@hotmail.com>
Date: Mon, 10 Mar 2008 13:11:37 -0500
Links: << >>  << T >>  << A >>
Hi Austin, 
I will check connected pins and come back. The worst thing is I am not
very familiar with FPGA and I am trying to fix everything from hardware
side, since software is accepted as working one...
24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data
for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,
no termination on it. There is no change from the last build. 
Strange thing is some boards work, some not, and some switching from time
to time.
Since the boys build the device, put two Atmega microcontrollers and FPGA
on same external reset circuit, I doubt that FPGA trying to start before
24MHz oscillator is up completely, and that lead to these 6MHz...
These 8MHz going from from FPGA through 51ohm to clock input of Atmega. 
Hope it is not sound as complete mess...
 

--
Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
More information at http://www.talkaboutelectronicequipment.com/faq.html


Article: 129929
Subject: Re: Virtex-4 VLX25 DCM problem
From: "Grubi" <dkolev@hotmail.com>
Date: Mon, 10 Mar 2008 13:19:14 -0500
Links: << >>  << T >>  << A >>
Hi Austin, 
I will check connected pins and come back. The worst thing is I am not
very familiar with FPGA and I am trying to fix everything from hardware
side, since software is accepted as working one...
24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data
for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,
no termination on it. There is no change from the last build. 
Strange thing is some boards work, some not, and some switching from time
to time.
Since the boys build the device, put two Atmega microcontrollers and FPGA
on same external reset circuit, I doubt that FPGA trying to start before
24MHz oscillator is up completely, and that lead to these 6MHz...
These 8MHz going from from FPGA through 51ohm to clock input of Atmega. 
Hope it is not sound as complete mess...
 

--
Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
More information at http://www.talkaboutelectronicequipment.com/faq.html


Article: 129930
Subject: Re: Virtex-4 VLX25 DCM problem
From: "Grubi" <dkolev@hotmail.com>
Date: Mon, 10 Mar 2008 13:29:34 -0500
Links: << >>  << T >>  << A >>
Here is more  - 24MHz coming from the oscillator through 68ohm terminating
resistor and goes to pin B10 and 8MHz goes out from T17 through 51 ohms to
clock input of Atmega. This track is less than half inch. Hope this helps,
somehow. 

Clock for configuration memory (17fxxx series, serial Flash) also going
out through 51 ohm resistor - and there are also problems sometimes. 

Probably you are talking me about internal connections, but I don't know
much about them. Will check and read about these, too. Thanks again
reading my looong explanations.

--
Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
More information at http://www.talkaboutelectronicequipment.com/faq.html


Article: 129931
Subject: Re: Virtex-4 VLX25 DCM problem
From: austin <austin@xilinx.com>
Date: Mon, 10 Mar 2008 13:27:09 -0700
Links: << >>  << T >>  << A >>
Grubi,

Since some parts work, and some don't:

-check when the DCM is reset(too soon, and that may be the issue)
-look at the clock in pin on passing and failing units (is there a
difference)?


Debugging this without looking inside is going to be extremely
difficult.  I suggest you look at how you can observe the DCM reset
signal first.

Austin

Article: 129932
Subject: Re: Virtex-4 VLX25 DCM problem
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 10 Mar 2008 14:48:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 10, 11:19=A0am, "Grubi" <dko...@hotmail.com> wrote:
> Hi Austin,
> I will check connected pins and come back. The worst thing is I am not
> very familiar with FPGA and I am trying to fix everything from hardware
> side, since software is accepted as working one...
> 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data
> for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,
> no termination on it. There is no change from the last build.
> Strange thing is some boards work, some not, and some switching from time
> to time.
> Since the boys build the device, put two Atmega microcontrollers and FPGA
> on same external reset circuit, I doubt that FPGA trying to start before
> 24MHz oscillator is up completely, and that lead to these 6MHz...
> These 8MHz going from from FPGA through 51ohm to clock input of Atmega.
> Hope it is not sound as complete mess...
>
> --
> Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp=
.arch.fpga/
> More information athttp://www.talkaboutelectronicequipment.com/faq.html

If you are completely in the dark:
Change the temperature with hairdryer and cold-spray, and note any
different behavior.
change the Vccint 10 percent up and down ( used to be simple, but more
tricky nowadays)
Load the oscillator frequency input with a 50 ohm resistor to either
ground or Vcco.
Put your finger or a small capacitor on the oscillator input.
Those were the "debugging methods" used decades ago, before logic
analyzers and sampling scopes.
The idea is to increase the likelihood of failure, and then deduce the
most likely cause.
Good luck
Peter Alfke

Article: 129933
Subject: Re: Virtex-4 VLX25 DCM problem
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 10 Mar 2008 16:11:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 10, 2:48=A0pm, Peter Alfke <pe...@xilinx.com> wrote:
> On Mar 10, 11:19=A0am, "Grubi" <dko...@hotmail.com> wrote:
>
>
>
> > Hi Austin,
> > I will check connected pins and come back. The worst thing is I am not
> > very familiar with FPGA and I am trying to fix everything from hardware
> > side, since software is accepted as working one...
> > 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data
> > for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,=

> > no termination on it. There is no change from the last build.
> > Strange thing is some boards work, some not, and some switching from tim=
e
> > to time.
> > Since the boys build the device, put two Atmega microcontrollers and FPG=
A
> > on same external reset circuit, I doubt that FPGA trying to start before=

> > 24MHz oscillator is up completely, and that lead to these 6MHz...
> > These 8MHz going from from FPGA through 51ohm to clock input of Atmega.
> > Hope it is not sound as complete mess...
>
> > --
> > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/co=
mp.arch.fpga/
> > More information athttp://www.talkaboutelectronicequipment.com/faq.html
>
> If you are completely in the dark:
> Change the temperature with hairdryer and cold-spray, and note any
> different behavior.
> change the Vccint 10 percent up and down ( used to be simple, but more
> tricky nowadays)
> Load the oscillator frequency input with a 50 ohm resistor to either
> ground or Vcco.
> Put your finger or a small capacitor on the oscillator input.
> Those were the "debugging methods" used decades ago, before logic
> analyzers and sampling scopes.
> The idea is to increase the likelihood of failure, and then deduce the
> most likely cause.
> Good luck
> Peter Alfke

Another "trick":
Make sure the oscillator is running before the FPGA is being turned
on.
That eliminates some reset timing problems.
Peter Alfke

Article: 129934
Subject: Re: Virtex-4 VLX25 DCM problem
From: mh <moazzamhussain@gmail.com>
Date: Mon, 10 Mar 2008 22:26:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 11, 4:11 am, Peter Alfke <pe...@xilinx.com> wrote:
> On Mar 10, 2:48 pm, Peter Alfke <pe...@xilinx.com> wrote:
>
>
>
> > On Mar 10, 11:19 am, "Grubi" <dko...@hotmail.com> wrote:
>
> > > Hi Austin,
> > > I will check connected pins and come back. The worst thing is I am not
> > > very familiar with FPGA and I am trying to fix everything from hardware
> > > side, since software is accepted as working one...
> > > 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data
> > > for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,
> > > no termination on it. There is no change from the last build.
> > > Strange thing is some boards work, some not, and some switching from time
> > > to time.
> > > Since the boys build the device, put two Atmega microcontrollers and FPGA
> > > on same external reset circuit, I doubt that FPGA trying to start before
> > > 24MHz oscillator is up completely, and that lead to these 6MHz...
> > > These 8MHz going from from FPGA through 51ohm to clock input of Atmega.
> > > Hope it is not sound as complete mess...
>
> > > --
> > > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
> > > More information athttp://www.talkaboutelectronicequipment.com/faq.html
>
> > If you are completely in the dark:
> > Change the temperature with hairdryer and cold-spray, and note any
> > different behavior.
> > change the Vccint 10 percent up and down ( used to be simple, but more
> > tricky nowadays)
> > Load the oscillator frequency input with a 50 ohm resistor to either
> > ground or Vcco.
> > Put your finger or a small capacitor on the oscillator input.
> > Those were the "debugging methods" used decades ago, before logic
> > analyzers and sampling scopes.
> > The idea is to increase the likelihood of failure, and then deduce the
> > most likely cause.
> > Good luck
> > Peter Alfke
>
> Another "trick":
> Make sure the oscillator is running before the FPGA is being turned
> on.
> That eliminates some reset timing problems.
> Peter Alfke





Hi Austin,
This discussion triggers a question in my mind about an issue related
to DCM that I faced a few years ago.

I was working with Xilinx Spartan-3 Kit employing XC3S1500 FPGA for
interfacing on PCI-Bus
using a custom core. I used a DCM (connected to PCI-clock) in my
design and the logic always stopped working after running for a few
minutes due to unavailability of clock. I contacted Xilinx support but
could not get any satisfactory
answer to the issue.

I thought that perhaps PCI-clock does not allow any phase locked loop
to be attached to it.

I then tried the on board oscillator, and even though I had three
clocks in my logic and I had to address some minor issues related to
multiple clock domains, the logic seems to be working so far.

Does PCI-clock allow Xilinx DCM to be attached (as clock multiplier) ?
Again, as posted by the original poster,
Can a DCM get halted after some time due to excessive internal
errors ?

/MH

Article: 129935
Subject: vhdl code realization
From: jshrini.vasu@gmail.com
Date: Tue, 11 Mar 2008 00:06:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everyone,

I have a issue with fpga design optimization. Can any body explain me
What is called "reorder path"? with any nice example with hardware
realization.

As per some book reference it says tht: The data flow which minimize
the critical path,..or more mean into: whenever multiple paths combine
with critical paths, and combined path can be reorderd such tht the
critical path can be moved closer to the destination register.

Hope to expect some good answers,..

sreeni,
Moog,Inc

Article: 129936
Subject: Virtex-5 FX when ? (III)
From: Udo <WeikEngOff@aol.com>
Date: Tue, 11 Mar 2008 03:17:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello Antti, Peter and ...,

yep, meanwhile many, many months later - the same question...
V5-FX?

Thanks and greetings
Udo

Article: 129937
Subject: Re: Virtex-4 VLX25 DCM problem
From: John McCaskill <jhmccaskill@gmail.com>
Date: Tue, 11 Mar 2008 05:56:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 10, 11:26 pm, mh <moazzamhuss...@gmail.com> wrote:


<snip>


> Hi Austin,
> This discussion triggers a question in my mind about an issue related
> to DCM that I faced a few years ago.
>
> I was working with Xilinx Spartan-3 Kit employing XC3S1500 FPGA for
> interfacing on PCI-Bus
> using a custom core. I used a DCM (connected to PCI-clock) in my
> design and the logic always stopped working after running for a few
> minutes due to unavailability of clock. I contacted Xilinx support but
> could not get any satisfactory
> answer to the issue.
>
> I thought that perhaps PCI-clock does not allow any phase locked loop
> to be attached to it.
>
> I then tried the on board oscillator, and even though I had three
> clocks in my logic and I had to address some minor issues related to
> multiple clock domains, the logic seems to be working so far.
>
> Does PCI-clock allow Xilinx DCM to be attached (as clock multiplier) ?
> Again, as posted by the original poster,
> Can a DCM get halted after some time due to excessive internal
> errors ?
>
> /MH

The PCI spec is not compatible with the DCMs. If you control the
entire bus, you can make it compatible.  If you are designing a PCI
card to go into any PCI system, you need to avoid using the PCI clock
as an input to a DCM.

The PCI spec allows the PCI clock frequency to be changed. I do not
know what percentage of systems actually do this, but the DCMs would
not be able to stay locked if this happened.

The PCI spec also allows the clock to be a spread spectrum clock to
help with EMI compliance.  I do not have the PCI spec with me now, but
I think that the the amount and rate of frequency change was within
the DCM spec on the Virtex-II and Virtex-4 FPGAs that I have
implemented PCI on. I do not know if it is within spec for the Spartan
series. However, even if the spread spectrum clocking is compatible
with the DCM, it reduces your jitter tolerance and jitter can cause a
DCM to lose lock.

On a Virtex-II 3000, we were able to just run the PCI clock through a
BUFG and use that directly for a 66MHz PCI interface.  On a Virtex-4
FX 40/60/100, we use the BUFIO and BUFR clocks for the PCI clock
domain for a 66 MHz PCI interface.

From your post, I get the impression that you wanted to use the PCI
clock as the main clock in your design.  I would suggest that you only
use IO clocks for IO, and have your own clock source for your main
clock.

Regards,

John McCaskill
www.FasterTechnology.com


Article: 129938
Subject: Contradicting messages from Xilinx' place and route/timing analyzer
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 11 Mar 2008 13:15:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
I just noticed a very weird if not outright scary behavior from the
par and trce tools in ISE.

For an example of what I mean, try to synthesize the following very
simple design for a xc4vlx80-12. You will have to turn off "Shift
register extraction" under synthesize/HDL options though. You might
also have to change place & route effort level to high as that is what
I had it set to when trying this out.

//////////////////////////////////////////////////////////////////////
module argh (input wire clk,
    input wire [17:0] a_i,b_i,
    output reg [47:0] result_mul);

   reg [17:0]          a1,a2,op_a,b1,b2,op_b;
   reg [47:0]          r1,r2;
   wire [47:0]         r;

   always @(posedge clk) begin
      a1   <= a_i; a2   <= a1; op_a <= a2;
      b1   <= b_i; b2   <= b1; op_b <= b2;
      r1 <= r; r2 <= r1; result_mul <= r2;
   end

   DSP48 #( .AREG(1), .BREG(1), .B_INPUT("DIRECT"), .CARRYINREG(1),
           .CARRYINSELREG(1), .CREG(0), .LEGACY_MODE("MULT18X18"),
           .MREG(0), .OPMODEREG(0), .PREG(1), .SUBTRACTREG(0) )
           dsp48_test
             ( .CLK(clk), .BCOUT(), .P(r), .PCOUT(), .A(op_a),
                         .B(op_b), .BCIN(), .C(48'b0), .CARRYIN(1'b0),
                         .CARRYINSEL(2'b00), .CEA(1'b1), .CEB(1'b1),
                         .CEC(1'b1), .CECARRYIN(1'b1),
                         .CECINSUB(1'b1), .CECTRL(1'b1), .CEM(1'b1),
                         .CEP(1'b1), .OPMODE(7'b0000101), .PCIN(),
                         .RSTA(1'b0), .RSTB(1'b0), .RSTC(1'b0),
                         .RSTCARRYIN(1'b0), .RSTCTRL(1'b0),
                         .RSTM(1'b0), .RSTP(1'b0), .SUBTRACT(1'b0) );
endmodule
//////////////////////////////////////////////////////////////////////


Anyway, when synthesizing this design I got the following in the place
& route logfile, indicating that this design will run at around 539
MHz. This is very odd as the DSP48 block should not be able to operate
at more than around 317 MHz in this configuration if I understand the
datasheet correctly. But there is no error or warning message in
argh.par or argh.twr.

argh.par: ------------------------------------------------------------------------------------------------------
argh.par:   Constraint                                |  Check  | Worst Case |  Best Case | Timing |   Timing   
argh.par:                                             |         |    Slack   | Achievable | Errors |    Score   
argh.par: ------------------------------------------------------------------------------------------------------
argh.par:   Autotimespec constraint for clock net clk | SETUP   |         N/A|     1.853ns|     N/A|           0
argh.par:   _BUFGP                                    | HOLD    |     0.255ns|            |       0|           0
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: 
argh.par: 
argh.par: All constraints were met.
argh.par: INFO:Timing:2761 - N/A entries in the Constraints list may indicate that the 
argh.par:    constraint does not cover any paths or that it has no requested value.


After this I add a constraint file with a 2.5ns constraint on the
period and get the following in the bottom of argh.par:



argh.par: ------------------------------------------------------------------------------------------------------
argh.par:   Constraint                                |  Check  | Worst Case |  Best Case | Timing |   Timing   
argh.par:                                             |         |    Slack   | Achievable | Errors |    Score   
argh.par: ------------------------------------------------------------------------------------------------------
argh.par:   TS_clk = PERIOD TIMEGRP "clk" 2.5 ns HIGH | SETUP   |     0.000ns|     2.500ns|       0|           0
argh.par:    50%                                      | HOLD    |     0.545ns|            |       0|           0
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: 
argh.par: 
argh.par: All constraints were met.


Note that the tool says that all constraints are met, even though the
following warning is located at the top of this file:


argh.par: WARNING:Timing:3232 - Timing Constraint 
argh.par:    "TS_clk = PERIOD TIMEGRP "clk" 2.5 ns HIGH 50%;"
argh.par:     fails the minimum period check for clock clk_BUFGP because the period constraint value (2500 ps) is less than the
argh.par:    minimum internal period limit of 3150 ps.   Please increase the period of the constraint to remove this timing
argh.par:    failure.



This warning message annoys me quite a bit because there is no
indication as to why the minimum internal period limit is 3150 ps. It
took me quite some time to find that the real cause of the error was
the DSP block. At first I thoguht there was some limit on the type of
clock bufer I was using or something similar before turning my
attention to the DSP48 block.

Similar behavior is shown by the trce tool in the argh.twr timing
report file; A warning at the top of the file even though the text at
the bottom says that all constraints were met.


I'm basically posting this so that people who google for "minimum
internal period limit" might be able to find this message and possibly
be helped by it if this is indeed their problem.


/Andreas

Article: 129939
Subject: Matlab, RS-232, Ethernet
From: satyam <satyam.dwivedi@gmail.com>
Date: Tue, 11 Mar 2008 06:49:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I want to interface matlab with the Xilinx Virtex-II pro board. Intent
is to give input from matlab to the FPGA and to read the ouput of FPGA
in matlab.

Problem is in interfacing speed. I need high speed interface, of the
order of 2 mega bits per second (Mbps). Seems RS-232 will be
inadequate for my purpose. From Documents interface through ethernet
seems to be a viable option but I am not sure. To summarize I want
answers and suggestions on following:

1). FPGA to PC communication by ethernet ?
2). What can be the maximum speed ?
3). How to transfer data on ethernet by matlab ?
4). Is it possible to write inputs (60 Mega bits) to some memory on
FPGA board and then read it from there to do the computation ?

Please let me know if you have any suggestion for me.

Thank You.

StYm

Article: 129940
Subject: BRAM synthesis question
From: Paul Boven <boven@jive.nl>
Date: Tue, 11 Mar 2008 14:55:20 +0100
Links: << >>  << T >>  << A >>
Hi everyone,

While trying to build a simple VGA driver, I'm running into trouble
getting my video-ram (actually, sample ram) to be synthesized as a dual
port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried
to describe the BRAM as instructed in the xst.pdf documentation, but as
soon as I try to read out the BRAM, the Synthesizer turns it into
distributed RAM. I wonder if anyone would be so kind as to help me
understand why?

The circuit consists of an 8 bit sampler which produces 2's complement
data. It is connected to my Spartan-3 kit and I want the data to be
displayed by the VGA port, as a primitive oscilloscope - just to verify
that I'm getting valid data from the sampler.
The display is generated by comparing the current vertical position
against the sample ram contents for the current horizontal position, and
drawing a pixel if they match -  repeat for every position as the VGA
display is scanned. This would undoubtedly benefit from more advanced
concepts like double-buffering, but I'm slowly working my way up to that.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity main is
	Port (clk: in STD_LOGIC;
		sample: in STD_LOGIC_VECTOR(7 downto 0)
		red, green, blue: out STD_LOGIC));
...
end main;

architecture Behavioural of main is

type bram_type is array (511 downto 0) of signed (7 downto 0);
signal BRAM: bram_type;
signal BRAM_addra: unsigned (8 downto 0) := "000000000";
signal BRAM_addrb: unsigned (8 downto 0) := "000000000";
signal vert: unsigned (9 downto 0) := "0000000000";

process(clk) -- Read data from the sampler
begin
if(clk'event and clk='1') then
...
	BRAM(to_integer(BRAM_addra)) <= signed(sample);
end if;
end process;

process(clk) -- Display VGA image
begin
if (clk'event and clk = '1')
...
	-- vert runs form 40 to 520, vert - 200 should center signed(0).
	if(BRAM(to_integer(BRAM_addrb)) = signed (vert  - 200)) then
		red <= '1'; green <= '1'; blue <= '1';
	else
		red <='0'; green <= '0'; blue <= '0';
	end if;
	BRAM_addrb <= BRAM_addrb + 1;
	(increment/reset BRAM_addrb and vert as appropriate to scan)
end if;
end process;

The code above gives me this warning: XST:2664 HDL ADVISOR - Unit <main>
: The RAM <Mram_BRAM> will be implemented on LUTs either because you
have described an asynchronous read or because of currently unsupported
block RAM features. If you have described an asynchronous read, making
it synchronous would allow you to take advantage of available block RAM
resources, for optimized device usage and improved timings. Please refer
to your documentation for coding guidelines.

I don't see (and would welcome any suggestions) why this is an
asynchronous read, as it only happens during 'clk' transitions.
If one would rather see the full vhd file, please see
http://www.xs4all.nl/~epboven/main.vhd

Now in order to sidestep this problem, I've introduced a signal bram_buffer:

signal bram_buffer: signed(7 downto 0)
...
	if(bram_buffer = signed(vert - 200) then
		red <= '1'; green <= '1'; blue <= '1';
...
	bram_buffer <= BRAM(to_integer(BRAM_addrb));

This does result in an implementation that uses a block ram, but
curiously the output from XST suggests that the buffer isn't actually
used at all:
INFO:Xst:2691 - Unit <main> : The RAM <Mram_BRAM> will be implemented as
a BLOCK RAM, absorbing the following register(s): <bram_buffer>.

So hooray, but as I just pipelined the BRAM output, my assumption was
that I would now be getting my samples one pixel 'late' and would need
to compensate for that - with the above message thrown in, I'm not sure
of that anymore.

Any comments welcome (please be gentle...)

Regards, Paul Boven.

Article: 129941
Subject: Re: BRAM synthesis question
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 11 Mar 2008 07:03:17 -0700
Links: << >>  << T >>  << A >>
Paul Boven wrote:

> While trying to build a simple VGA driver, I'm running into trouble
> getting my video-ram (actually, sample ram) to be synthesized as a dual
> port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried
...
> Any comments welcome 

Consider a fifo.

          -- Mike Treseler

Article: 129942
Subject: Re: BRAM synthesis question
From: Dave <dhschetz@gmail.com>
Date: Tue, 11 Mar 2008 07:09:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 11, 9:55 am, Paul Boven <bo...@jive.nl> wrote:
> Hi everyone,
>
> While trying to build a simple VGA driver, I'm running into trouble
> getting my video-ram (actually, sample ram) to be synthesized as a dual
> port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried
> to describe the BRAM as instructed in the xst.pdf documentation, but as
> soon as I try to read out the BRAM, the Synthesizer turns it into
> distributed RAM. I wonder if anyone would be so kind as to help me
> understand why?
>
> The circuit consists of an 8 bit sampler which produces 2's complement
> data. It is connected to my Spartan-3 kit and I want the data to be
> displayed by the VGA port, as a primitive oscilloscope - just to verify
> that I'm getting valid data from the sampler.
> The display is generated by comparing the current vertical position
> against the sample ram contents for the current horizontal position, and
> drawing a pixel if they match -  repeat for every position as the VGA
> display is scanned. This would undoubtedly benefit from more advanced
> concepts like double-buffering, but I'm slowly working my way up to that.
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.NUMERIC_STD.ALL;
>
> entity main is
>         Port (clk: in STD_LOGIC;
>                 sample: in STD_LOGIC_VECTOR(7 downto 0)
>                 red, green, blue: out STD_LOGIC));
> ...
> end main;
>
> architecture Behavioural of main is
>
> type bram_type is array (511 downto 0) of signed (7 downto 0);
> signal BRAM: bram_type;
> signal BRAM_addra: unsigned (8 downto 0) := "000000000";
> signal BRAM_addrb: unsigned (8 downto 0) := "000000000";
> signal vert: unsigned (9 downto 0) := "0000000000";
>
> process(clk) -- Read data from the sampler
> begin
> if(clk'event and clk='1') then
> ...
>         BRAM(to_integer(BRAM_addra)) <= signed(sample);
> end if;
> end process;
>
> process(clk) -- Display VGA image
> begin
> if (clk'event and clk = '1')
> ...
>         -- vert runs form 40 to 520, vert - 200 should center signed(0).
>         if(BRAM(to_integer(BRAM_addrb)) = signed (vert  - 200)) then
>                 red <= '1'; green <= '1'; blue <= '1';
>         else
>                 red <='0'; green <= '0'; blue <= '0';
>         end if;
>         BRAM_addrb <= BRAM_addrb + 1;
>         (increment/reset BRAM_addrb and vert as appropriate to scan)
> end if;
> end process;
>
> The code above gives me this warning: XST:2664 HDL ADVISOR - Unit <main>
> : The RAM <Mram_BRAM> will be implemented on LUTs either because you
> have described an asynchronous read or because of currently unsupported
> block RAM features. If you have described an asynchronous read, making
> it synchronous would allow you to take advantage of available block RAM
> resources, for optimized device usage and improved timings. Please refer
> to your documentation for coding guidelines.
>
> I don't see (and would welcome any suggestions) why this is an
> asynchronous read, as it only happens during 'clk' transitions.
> If one would rather see the full vhd file, please seehttp://www.xs4all.nl/~epboven/main.vhd
>
> Now in order to sidestep this problem, I've introduced a signal bram_buffer:
>
> signal bram_buffer: signed(7 downto 0)
> ...
>         if(bram_buffer = signed(vert - 200) then
>                 red <= '1'; green <= '1'; blue <= '1';
> ...
>         bram_buffer <= BRAM(to_integer(BRAM_addrb));
>
> This does result in an implementation that uses a block ram, but
> curiously the output from XST suggests that the buffer isn't actually
> used at all:
> INFO:Xst:2691 - Unit <main> : The RAM <Mram_BRAM> will be implemented as
> a BLOCK RAM, absorbing the following register(s): <bram_buffer>.
>
> So hooray, but as I just pipelined the BRAM output, my assumption was
> that I would now be getting my samples one pixel 'late' and would need
> to compensate for that - with the above message thrown in, I'm not sure
> of that anymore.
>
> Any comments welcome (please be gentle...)
>
> Regards, Paul Boven.

The read operation from a BRAM needs to be clocked. Either feed the
read address through a register before using it to index the RAM, or
register the output of the RAM. Either of these result in a 1 clock
delay between the read address and the output data. There are code
templates online in the XST users guide. Hope this helps.

Article: 129943
Subject: Ann: New FPGA beginner's Video guide
From: "Tony Burch" <tony@burched.com.au>
Date: Wed, 12 Mar 2008 01:12:05 +1100
Links: << >>  << T >>  << A >>
Hi all,



I have just released a new online Video guide called "The BurchED Getting 
Started with Xilinx FPGAs Video Guide" http://www.BurchED.com



It is an easy step-by-step guide for FPGA beginners. I go all the way 
through from "What is an FPGA?" right up to compiling designs and 
downloading to your FPGA board.



You can log in to the site whenever you want and watch the videos, including 
any additional ones that I will put up over time.



There's a Free Membership area where you can watch some videos for free.



* FPGAs for Beginners - the Top 6 Questions answered

* How to choose an FPGA board

* An independent review of available FPGA boards

* What to do when you first get your FPGA board

* How to download and install the free Xilinx design software



There's also an introductory offer on the full video guide, which includes 
18 videos on getting started with Xilinx FPGAs. Some of the benefits are:



* Save time and effort when getting started with FPGAs

* Avoid the big mistakes that often derail first time FPGA users

* Save money - advice to lower your cost when getting an FPGA board

* Expand your design options by putting FPGAs in your toolbox

* Achieve the satisfaction and fun of designing your own FPGA circuits

* Amaze your colleagues with your new FPGA skills

* Gain the skills and confidence needed to go on and make more complex 
designs



I look forward to seeing you over there. Grab the Free membership & have a 
look at the introductory offer on the full video guide 
http://www.BurchED.com



Kind regards,



Anthony Burch

BurchED - Making it easy to get started with FPGAs



PS. A note for University Lecturers:

University & company site licenses are available. Minimise the amount of 
lecture time that you spend teaching FPGA basics. Let your students do this 
video course at home. Please email me for details about great value site 
licenses.





Article: 129944
Subject: Re: vhdl code realization
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 11 Mar 2008 07:14:05 -0700
Links: << >>  << T >>  << A >>
jshrini.vasu@gmail.com wrote:

> I have a issue with fpga design optimization. Can any body explain me
> What is called "reorder path"? with any nice example with hardware
> realization.

It is nice that I tell synthesis
what Fmax is, and synthesis does a fine job
wiring up the LUTs and optimizing the paths for me.

      -- Mike Treseler

http://home.comcast.net/~mike_treseler/count_enable.pdf
http://home.comcast.net/~mike_treseler/count_enable_map.pdf

Article: 129945
Subject: Re: Matlab, RS-232, Ethernet
From: Dave <dhschetz@gmail.com>
Date: Tue, 11 Mar 2008 07:18:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 11, 9:49 am, satyam <satyam.dwiv...@gmail.com> wrote:
> Hi,
>
> I want to interface matlab with the Xilinx Virtex-II pro board. Intent
> is to give input from matlab to the FPGA and to read the ouput of FPGA
> in matlab.
>
> Problem is in interfacing speed. I need high speed interface, of the
> order of 2 mega bits per second (Mbps). Seems RS-232 will be
> inadequate for my purpose. From Documents interface through ethernet
> seems to be a viable option but I am not sure. To summarize I want
> answers and suggestions on following:
>
> 1). FPGA to PC communication by ethernet ?
> 2). What can be the maximum speed ?
> 3). How to transfer data on ethernet by matlab ?
> 4). Is it possible to write inputs (60 Mega bits) to some memory on
> FPGA board and then read it from there to do the computation ?
>
> Please let me know if you have any suggestion for me.
>
> Thank You.
>
> StYm

These may help:

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=345&objectType=File
http://www.mathworks.com/products/instrument/supportedio13782.html

All hail the power of google!

Article: 129946
Subject: Re: BRAM synthesis question
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 11 Mar 2008 14:19:23 -0000
Links: << >>  << T >>  << A >>
Hi Paul,
Yeah, if you look at your code, you're trying to do an asynchronous read. I 
suggest you try simulating your design and also a design where you 
instantiate a block ram. You'll be able to compare and see clearly what the 
block ram does.
HTH., Syms. 



Article: 129947
Subject: Could I develop a new gui using java based on the script language of
From: wicky <wicky.zhang@gmail.com>
Date: Tue, 11 Mar 2008 07:58:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
I found Chipscope is too difficult to learn for college students, it
has too much options. I want to develop a simple gui software and
using it in a 8086/8088 FPGA embedded system. For example, students
can understand a bus transaction with just a simple mouse click in
this software, instead of setting so much options in the tranditional
Chipscope software. Can anyone give me some information about this
work? Thank you!

Best Regards,

Wicky

Article: 129948
Subject: Re: Virtex-4 VLX25 DCM problem
From: austin <austin@xilinx.com>
Date: Tue, 11 Mar 2008 07:59:22 -0700
Links: << >>  << T >>  << A >>
mh,

John has answered your question of PCI<>DCM.

-snip-

> Can a DCM get halted after some time due to excessive internal
> errors ?
> 
> /MH

The DCM "stops" and drops the LOCKED signal if the tap address runs
over, or under, the length of the delay line.  That happens when the
clock changes frequency, or has drop-outs (missing pulses).

A PLL would "tolerate" such clocks, but the DCM being a digital state
machine, does not.

If the clock stops altogether, LOCKED will not drop (it is synchronous
with CLKIN), thus we have a CLOCK_STOPPED status bit that has to be
monitored (to know what is going on).  This status bit is asynchronously
set, so no CLKIN is required.

Austin

Article: 129949
Subject: Re: Could I develop a new gui using java based on the script language
From: Jeff Cunningham <jcc@sover.net>
Date: Tue, 11 Mar 2008 11:25:17 -0400
Links: << >>  << T >>  << A >>
wicky wrote:
> I found Chipscope is too difficult to learn for college students, it

Yes but isn't college supposed to prepare them for the real world?

> has too much options. I want to develop a simple gui software and
> using it in a 8086/8088 FPGA embedded system. For example, students
> can understand a bus transaction with just a simple mouse click in
> this software, instead of setting so much options in the tranditional
> Chipscope software. Can anyone give me some information about this
> work? Thank you!

Couldn't the instructor set up chipscope and then save all the options? 
Then the student would just have to reload the saved project file, and 
the bus transaction would be there all optimally displayed for 
understanding.

-Jeff



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