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 154275

Article: 154275
Subject: Re: Global Reset using Global Buffer
From: HT-Lab <hans64@htminuslab.com>
Date: Wed, 19 Sep 2012 21:31:49 +0100
Links: << >>  << T >>  << A >>
On 19/09/2012 15:38, jonesandy@comcast.net wrote:
> On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote:
>> If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231.
>
> I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs.
>
> If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue.
>
> There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset.

Right!

http://microelectronics.esa.int/asic/fpga_001_01-0-2.pdf

Skip to section 3.1.

In a nutshell, the Nasa Wire satellite was lost due to the use of a 
synchronous reset.

Hans
www.ht-lab.com


> Let's just leave it at that, without all the pontifications invoking "never" (or "always").
>
> Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway.
>
> Andy
>


Article: 154276
Subject: Re: Global Reset using Global Buffer (long!)
From: gtwrek@sonic.net (Mark Curry)
Date: Thu, 20 Sep 2012 00:22:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <47cbefa7-3c40-4131-974e-0a1a09b61d3f@googlegroups.com>,
Carl  <carwer0@gmail.com> wrote:
>An article on the local/global and synchronous/asynchronous aspects of resets:
>
>http://www.fpga-dev.com/resets-make-them-synchronous-and-local/

Okay, long post - this should probably go somewhere else, but here's 
my reponse - it's some ideas that I've often thought of when seeing this
advice like this, but never get "pen to paper" as it were.

Thinking about resets are good, and having a good strategy, 
very important, but I disagree with a lot of this advice.
And this type of advice been coming out of the FPGA companies for 
a while.  

But here's my 4 cents.  (Too long for just 2 cents.)

I come from an ASIC background - where logic's cheap.  ( I know this
is an FPGA newsgroup - bare with me. ) 

There, for all of our designs we used a global resets streategy, which 
ASYNCHRONOUSLY reset FFs. 

i.e. in verilog:

Example 1.

reg foo;
always @( posedge clk or negedge reset_n )
  if( ~reset_n )
    foo <= 0;
  else
    foo <= bar;

The reset_n input to the module was generated near the 
top level of the chip.  At the top level, the main system
reset would have it's de-assertion edge synchronized to each
clock domain - effectively creating a per-clock reset 
signal.	 (I'm leaving out a LOT of qualifiers for this
including control of reset during test, etc.  But the
key, the resets are generated at the top-level globally).

Furthermore, we reset EVERTHING that could be reset.

The requirements for the reset to work:
  1.  The input reset needs to be appropriately de-glitched
      to avoid false assertions or de-assertions.  

  2.  It's pulse width large enough to be capture by 
      the async input (on the order of nanoseconds)

That's it.  You meet the above requirements, you'll safely enter the
reset state.  You'll succesfully exit the reset state - once the reset
de-asserts AND THE CLOCK is running.  If the clocks not running, you'll
stay reset.
 
The advantage of this approach:

Point 1.   - You're always right.  You can't hurt anything be resetting 
  a FF.  

Point 2.   - Simulating bringup is faster - perhaps MUCH faster.  I've 
  spent sometimes weeks chasing the "sea-of-red" bring ups in 
  simulation - the results of X-Pessimism.  I've seen all sorts of 
  kludge "demeta" tricks in simulation to work around these issue - and
  there just that - Kludge testbench work that usually offers nothing
  towards to the reliability of the design.

Point 3.   - Reducing X's in simulation (by resetting everything) also 
   reduces the chances of X-Optimism.  A much lower occuring problem, 
   but one with a larger penalty if missed (RTL sim vs. gates 
   mismatch).

The disadvantages - it's not optimal.  You may waste resources 
distributing the resets, and meeting the timing of the 
reset recovery path.  Note that all modern STA tools have
no trouble checking this timing.

Ask any business manager if this is the correct priority:
 
 1. Correct, and Reliable. 
 2. Faster debug and verification.
 3. Optimal

You won't get much argument.  And that 3rd objective will probably be
MUCH lower that the first two.

The amount of logic "wasted" on this strategy, is tiny in this deep 
sub-micron age.  We even used the same clock tree methodology for
distributing the resets.  Wasteful - sure.  But who cares?

After a while of that I came over to FPGAs.  FPGA's haven't been 
designed to waste a global low-skew route on this async reset.  
So, I switched to using synchronous resets:

Example 2.

reg foo;
always @( posedge clk )
  if( ~reset_n )
    foo <= 0;
  else
    foo <= bar;

Again the reset is generated globally, with de-assertion edge 
synchronized to respective clock.

The requirements for reset to work : same as above PLUS:

  3.  You're clock must be running to enter reset.

A normally simple-to-meet requirement, but can lead to perplexing debug 
in areas around non-free running clocks (i.e. around PLLs, and other 
clock-management logic).

Again, I reset EVERYTHING that can be reset.  

This strategy is not too different that the first.  Some extra 
head-scratching to be sure we're okay with extra reset requirement.  
But in general it works.

The advantages and disadvantages of this approach are similar to the 
first case.  The back end tools must meet timing on all reset
paths.  All FPGA tools will check this - the reset's basically just
like any other signal, albeit usually with a larger fanout.

To alleviate the large fanout - if it's even a problem, I can just
pipeline it (at the top level - globally!) a few times.  Then allow 
the tool to do any neccesary register duplication and perhaps register 
balancing.  The back end tools have solved this problem for me.

This leads my next evolution in resets:  "Selective" reseting.  

As many designers are apt to point out, EVERYTHING does not need
to be reset.  This is true.  Datapath logic is probably safe to leave 
un-initialized.

Example 3.  

reg [ 7 : 0 ] foo_data;
reg foo_control;
always @( posedge clk )
  if( ~reset_n )
  begin
    foo_control <= 0;
    //foo_data <= 0;
  end
  else
  begin
    foo_control <= bar;
    foo_data <= some_data;
  end

Here the control signal "foo_control" is reset.  The datapath element
"foo_data" is not.  And I usually code it just as above with the 
reset clause explicity commented out.  

The advantage of this approach - we can pick up a lot of optimizations
over reseting everything.  Especially in targetting delay shift 
registers (i.e. SRL16s in Xilinx).

But the disadvantages - slower coding, and the risk of missing a needed
reset.  When I'm coding a low-level module - possible one that's going
to be shared across many FPGAs- I need to stop and think a bit more on
what must be reset, and what's safe to leave uninitialized.  Do I know
of all use cases of this module?  Will it be safe in all cases to not
reset this signal?  This is often a hard requirement to decide.  You 
aften don't have all the information at the time of the coding to 
make this decision.  

So often I punt and leave the reset in - especially when
I bringup first testbenches and see that dreaded "sea-of-red".  
If I suspect its got ANYTHING to do with that uninitialized signal - 
that reset's going back in.  I can always go back in and re-comment
out the reset assignement, to be more optimal.  

But once the design is right how often will a designer be given the 
time to go back in and make it more "optimal"?  Probably only when
pushed into a corner.

The last style, often touted by FPGA companies, basically boils down 
to - don't reset at all.  The design comes up out of FPGA configuration
in a known, default state.  Often the synthesis tools can be configured
to adjust this default state with init values:

Example 4.
reg [ 7 : 0 ] foo_data = 0;
reg foo_control = 0;
always @( posedge clk )
  begin
    foo_control <= bar;
    foo_data <= some_data;
  end

I.e. the synthesis tool uses the verilog init value as the configuration
time value.   Here, reset's are the exception not the rule.  Only reset 
those very few elements that explicitly require it, and must see that 
edge.

Advantages of this : an optimal design.

The biggest drawback... FPGA Configuration is usaully NOT equal to 
RESET.  Most of my boards have at least some kind of push-button reset, 
probably another controlled by some sort of processor.  This reset is 
a distinct operation - quite seperate from FPGA "CONFIG". 

Plus, well, I'm very hesitant with this approach.  Reset and 
initialization problems can lie hidden for a long time.  During bringup,
often a lot of things are in flux, and a random init problem is often 
written off as some random event, and ignored.  "Hey I just ran it 
again it worked this time."

So the problem lies hidden much longer.  Months down the line when 
my manufacturing line ( or worse - customer ) comes back to be and 
says, "Hey I sometimes have to reset this thing twice to get it to 
work".  I'd be MUCH more comfortable in this situation knowing that 
I had a solid reset in my FPGA design.

"Correct and Reliable" has priority over "Optimal" for me.

Regards,

Mark




Article: 154277
Subject: Re: Global Reset using Global Buffer (long!)
From: jonesandy@comcast.net
Date: Thu, 20 Sep 2012 11:09:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Mark,

Nice write-up! In the end, if you count up all the time (money) spent deter=
mining AND VERIFYING what does not NEED to be reset, you'd have been better=
 off resetting everything to start with, and only pulling out the reset whe=
re it kills your utilization (by kill, I don't mean raises util from 85% to=
 86%, I mean it doesn't fit!).=20

The pipe-lining/retiming trick for handling fanout on the synchronous reset=
 also works great for synchronously deasserted asynchronous resets!

When coding a process that has some registers reset and others not, if you =
use the familiar "reset ... elsif clock ..." structure, your fanout on rese=
t may not be reduced, because every register that saved a reset, added a cl=
ock enable (or another input to existing clock enable logic).=20

When I have both reset and non-reset signals/variables in the same process =
(e.g. ram arrays, etc.), I use the following structure to avoid clock disab=
le on non-reset signals/variables:

process (clk, rst) is
begin
   clocked: if rising_edge(clk) then
      -- logic assignments here
   end if clocked;
   reset: if rst then=20
      -- reset assignments here
   end if reset;
end process;

Although this style works fine for the general case (when everything is res=
et), I do not use this style unless I actuall need it. The reason is, in th=
e conventional reset elsif clock structure, you will get synthesis warnings=
 (from synplify at least) about feedback multiplexers on non-reset register=
s. You won't get those warnings for them if you use the method above. This =
also makes the above approach rarer, which stands out for the reviewer, whe=
re it gets extra attention to make sure that everything that should (can?) =
be reset is reset.

The same clock enable problem also happens when you use an "if reset else l=
ogic" structure for a synchronous reset. Nothing after that "else" executes=
 when reset is true, which results in extra clock enable logic on non-reset=
 registers. Use a similar approach to the above, by moving the (synchronous=
) reset assignments to their own if-statement just before the end of the cl=
ocked if-statement:

process (clk) is
begin
   if rising_edge(clk) then
      -- logic assignments here
      if rst then
         -- reset assignments here
         -- to avoid clock enables
         -- on non-reset registers
      end if;
   end if;
end process;

Strange how I didn't see any of this in that white paper written by the "ex=
perts"...

Andy

Article: 154278
Subject: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Sun, 23 Sep 2012 00:57:27 -0500
Links: << >>  << T >>  << A >>
hi
i would like to drive a Digital to analog converter(AD1933) with a cpld,
here is what i'm trying to do: i have a micro controller that generate
25Mbps DAC data but is not capable of driving the DAC through high speed
SPI(i need over 35MHz spi interface), so i decided to drive the dac with
cpld or fpga,
since i don't want to increase project cost by using fpga so i prefer to
use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is
capable of driving the dac at this rate, any one have any idea about the
feasibility of this plan??
tnx in advance for help
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154279
Subject: multi-source errors
From: smileforthecamerahotshot@gmail.com
Date: Sat, 22 Sep 2012 23:44:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Any help is appreciated. I get errors of the following sort:

"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connec=
ted to multiple drivers."

The source for the entire unit in question is as follows:

module tst_1(
    input rst,
    input clk,
    output [7:0] led
);
    parameter s_0 =3D 2'b00;
    parameter s_1 =3D 2'b01;
    parameter s_2 =3D 2'b10;
    parameter s_3 =3D 2'b11;

    reg [1:0] state;
    reg [7:0] ram[0:15];=20
    reg [7:0] regs[0:7];

    initial begin
        state <=3D s_0;
        end

    always @(posedge clk) begin
        if (rst =3D=3D 1'b1)
            state <=3D s_0;
        else begin
            case (state)
                s_0: begin
                    ram[15] <=3D 8'h00;
                    state <=3D s_1;
                    end
                s_1: begin
                    regs[0] <=3D ~ram[8];
                    ram[15][0] <=3D 1'b1;
                    ram[15][1] <=3D 1'b0;
                    state <=3D s_2;
                    end
                s_2: begin
                    ram[7] <=3D regs[0];
                    ram[15][2] <=3D ~regs[0][7];
                    ram[15][3] <=3D regs[0][3];
                    state <=3D s_3;
                    end
                s_3: begin
                    ram[8] <=3D ram[7] ^ ram[15];
                    state <=3D s_1;
                    end
                default:
                    state <=3D s_0;
                endcase
            end
        end
    assign led =3D regs[0];
endmodule

For the interested, I get multi-source errors on ram[15][3], ram[15][2], an=
d ram[15][0]... but not ram[15][1]. Since the signals in question are all d=
riven from different states within the same FSM, I am not sure why this is =
considered multiple drivers. I am sure this is something obvious to the wel=
l-informed. Any ideas?

Article: 154280
Subject: JTAG3-parallel cable on SPARTAN-3 digilent Starter kit
From: "gokulaka" <3667@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:02 -0500
Links: << >>  << T >>  << A >>
Hi all,
I have been trying to make the JTAG3-parallel cable with SPI work with
spartan-3 board on red-hat linux(both from digilent)
The Jtag3 seems to detect the fpga and flash in chain but it does not
identify it. Have any of you run into this problem??

Also I am sure the s/w and the board works as I can program the same FPGA
with same PC settings (using iMPACT) with the older JTAG-parallel cable
from xilinx that supports 2.8V.

please help!!

Thanks a bunch,
gokul

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

Article: 154281
Subject: How to estimate PEAK power consumption on Xilinx FPGA ?
From: "eulia" <3676@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:07 -0500
Links: << >>  << T >>  << A >>
Hi,

Is there anyway to estimate "PEAK power consumption" using an Xilinx XPower
analyzer ?

I think the "Summar" page shows AVERAGE power consumption.

Thanks,

Jeong-Gun

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

Article: 154282
Subject: Error while running implementation through unix command line
From: "gaurav3110" <3677@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:13 -0500
Links: << >>  << T >>  << A >>

Hello,

 

I am new to Xilinx and bash scripting. I am using Xilinx 13.4. I am trying
to run implementation(ngdbuild, map, par etc) to create the bit file
through a bash script, but I am getting an error. Following is the snippet
of my error :-

 

Running synthesis...

bash -c "cd synthesis; ./synthesis.sh"
xst -ifn system_xst.scr -intstyle silent
Running XST synthesis ...
PMSPEC -- Overriding Xilinx file
</tools/Xilinx/13.4/ISE_DS/EDK/virtex5/data/virtex5.acd> with local file
</tools/Xilinx/13.4/ISE_DS/ISE/virtex5/data/virtex5.acd>
XST completed
error status of previous command:0
=> Starting xst: Xst log file is: no_file.syr
Using xst file - no_file.xst

 

ERROR:Xst:427 - Entry File no_file.xst not found

 

 Can I get some help on this?

 

Thanks,

Gaurav.


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

Article: 154283
Subject: Getting in to the industry
From: "James823" <3681@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:27 -0500
Links: << >>  << T >>  << A >>
Hi,
I'm new to FPGAs but would like to get into the industry. Aside from
building and playing around with toy projects, what can I do to help put me
ahead of the other EE graduates?
What kind of projects could be attempted with a starter kit that would put
hairs on my chest so to speak?

Thanks
James

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

Article: 154284
Subject: edge matching
From: "rohitbisht" <3698@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:35 -0500
Links: << >>  << T >>  << A >>
Hello 

1. I'am a beginner in fpga.and want some help.
I'am trying to write code for matching rising edges of two different pulse
train signa,so that AND operation can be performed b/w them .
synchronization is must for carrying the AND  operation.Kindly suggest some
idea.

2.how is it possible to generate signals at every rising egde of a given
signal where the frequency of new signal is defined by the taking (present
and just previous rising egde)for frequency calculation and new signal will
be generated at this present rising edge of given signal '

seeking your valuable ideas. 

thanks in advance.

regards

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

Article: 154285
Subject: multi-source errors
From: "sftchs" <3730@embeddedrelated>
Date: Sun, 23 Sep 2012 13:03:53 -0500
Links: << >>  << T >>  << A >>
Any help is appreciated. I get multi-source errors on signals that are
being driven by different states in the same FSM and I'm not sure why. Here
is one of the multi-source errors that I get:

"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is
connected to multiple drivers."

and here is the source for the entire unit

module tst_1(
    input rst,
    input clk,
    output [7:0] led
);
    parameter s_0 = 2'b00;
    parameter s_1 = 2'b01;
    parameter s_2 = 2'b10;
    parameter s_3 = 2'b11;

    reg [1:0] state;
    reg [7:0] ram[0:15]; 
    reg [7:0] regs[0:7];

    initial begin
        state <= s_0;
        end

    always @(posedge clk) begin
        if (rst == 1'b1)
            state <= s_0;
        else begin
            case (state)
                s_0: begin
                    ram[15] <= 8'h00;
                    state <= s_1;
                    end
                s_1: begin
                    regs[0] <= ~ram[8];
                    ram[15][0] <= 1'b1;
                    ram[15][1] <= 1'b0;
                    state <= s_2;
                    end
                s_2: begin
                    ram[7] <= regs[0];
                    ram[15][2] <= ~regs[0][7];
                    ram[15][3] <= regs[0][3];
                    state <= s_3;
                    end
                s_3: begin
                    ram[8] <= ram[7] ^ ram[15];
                    state <= s_1;
                    end
                default:
                    state <= s_0;
                endcase
            end
        end
    assign led = regs[0];
endmodule

For the interested, I get multi-source errors on ram[15][3], ram[15][2],
and ram[15][0]... but not ram[15][1]. I'm sure this must be something
obvious to the well-trained.

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

Article: 154286
Subject: Re: How to estimate PEAK power consumption on Xilinx FPGA ?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 23 Sep 2012 18:53:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
eulia <3676@embeddedrelated> wrote:
> Hi,

> Is there anyway to estimate "PEAK power consumption" using an Xilinx XPower
> analyzer ?

> I think the "Summar" page shows AVERAGE power consumption.

What do you mean by peak?

You have to have some capacitors on the supply lines, which
will average out any transients.

For CMOS, other than quiescient power (leakage current) power
occurs when a gate changes state, and for a very short time.

As you can't predict accurately enough the transition time, you
can't predict how many will transition in a given femtosecond.

Now, you might want the average over a somewhat shorter time scale,
especially as you might want to know how to divide up the required
capacitance, but peak really doesn't have much meaning.

-- glen

Article: 154287
Subject: Re: Getting in to the industry
From: rickman <gnuarm@gmail.com>
Date: Sun, 23 Sep 2012 16:17:01 -0400
Links: << >>  << T >>  << A >>
On 9/23/2012 2:03 PM, James823 wrote:
> Hi,
> I'm new to FPGAs but would like to get into the industry. Aside from
> building and playing around with toy projects, what can I do to help put me
> ahead of the other EE graduates?
> What kind of projects could be attempted with a starter kit that would put
> hairs on my chest so to speak?
>
> Thanks
> James

There are a lot of industry sectors that use FPGAs.  You would do well 
to learn specifics about designs in sectors you are interested in 
working.  For example, a lot of DOD folks do digital receiver designs. 
So if you want to work in DOD learning something about digital receivers 
would serve you well.

Likewise there are key areas in each sector, so first figure out who you 
want to work for and then go for the in depth learning of their needs. 
This goes for all aspects of the job too.  Before you interview with a 
company, learn as much as you can about the company and the job.

Rick

Article: 154288
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Tim Wescott <tim@seemywebsite.please>
Date: Sun, 23 Sep 2012 15:26:49 -0500
Links: << >>  << T >>  << A >>
On Sun, 23 Sep 2012 00:57:27 -0500, nba83 wrote:

> hi i would like to drive a Digital to analog converter(AD1933) with a
> cpld, here is what i'm trying to do: i have a micro controller that
> generate 25Mbps DAC data but is not capable of driving the DAC through
> high speed SPI(i need over 35MHz spi interface), so i decided to drive
> the dac with cpld or fpga,
> since i don't want to increase project cost by using fpga so i prefer to
> use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld
> is capable of driving the dac at this rate, any one have any idea about
> the feasibility of this plan??
> tnx in advance for help

How are you going to get data into your CPLD at that rate?  Parallel?  
Some other serial interface that also needs to run at 35MHz or more?

Your feasibility may break up on other rocks than whether the CPLD is up 
to it.

Having said that -- to my beginner's eyes a parallel in, serial out, 
35MHz SPI should be doable with a part like that.

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

Article: 154289
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: rickman <gnuarm@gmail.com>
Date: Sun, 23 Sep 2012 16:27:01 -0400
Links: << >>  << T >>  << A >>
On 9/23/2012 1:57 AM, nba83 wrote:
> hi
> i would like to drive a Digital to analog converter(AD1933) with a cpld,
> here is what i'm trying to do: i have a micro controller that generate
> 25Mbps DAC data but is not capable of driving the DAC through high speed
> SPI(i need over 35MHz spi interface), so i decided to drive the dac with
> cpld or fpga,
> since i don't want to increase project cost by using fpga so i prefer to
> use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is
> capable of driving the dac at this rate, any one have any idea about the
> feasibility of this plan??
> tnx in advance for help

Without looking at the data sheet, I am pretty sure these parts can 
drive a 35 MHz serial shift register.  35 MHz is pretty slow for any 
programmable logic part.

How will the CPLD talk to the micro?  I assume you plan to use a 
parallel, memory mapped interface?  Can your MCU keep up with the data 
speed?

Rick

Article: 154290
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: rickman <gnuarm@gmail.com>
Date: Sun, 23 Sep 2012 16:52:20 -0400
Links: << >>  << T >>  << A >>
On 9/23/2012 4:27 PM, rickman wrote:
> On 9/23/2012 1:57 AM, nba83 wrote:
>> hi
>> i would like to drive a Digital to analog converter(AD1933) with a cpld,
>> here is what i'm trying to do: i have a micro controller that generate
>> 25Mbps DAC data but is not capable of driving the DAC through high speed
>> SPI(i need over 35MHz spi interface), so i decided to drive the dac with
>> cpld or fpga,
>> since i don't want to increase project cost by using fpga so i prefer to
>> use cpld XC95XX(XC95144) for this application, i'm not sure if this
>> cpld is
>> capable of driving the dac at this rate, any one have any idea about the
>> feasibility of this plan??
>> tnx in advance for help
>
> Without looking at the data sheet, I am pretty sure these parts can
> drive a 35 MHz serial shift register. 35 MHz is pretty slow for any
> programmable logic part.
>
> How will the CPLD talk to the micro? I assume you plan to use a
> parallel, memory mapped interface? Can your MCU keep up with the data
> speed?
>
> Rick

BTW, there are some very low cost FPGAs available, around $3.  Check out 
the Lattice ice40 series.

Rick

Article: 154291
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 24 Sep 2012 00:04:06 GMT
Links: << >>  << T >>  << A >>
"nba83" <3224@embeddedrelated> wrote:

>hi
>i would like to drive a Digital to analog converter(AD1933) with a cpld,
>here is what i'm trying to do: i have a micro controller that generate
>25Mbps DAC data but is not capable of driving the DAC through high speed
>SPI(i need over 35MHz spi interface), so i decided to drive the dac with
>cpld or fpga,
>since i don't want to increase project cost by using fpga so i prefer to
>use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is
>capable of driving the dac at this rate, any one have any idea about the
>feasibility of this plan??

It shouldn't be a problem. I use these CPLDs for rescaling VGA
resolution TFT displays at reduced color depths.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 154292
Subject: Re: multi-source errors
From: Gabor <gabor@szakacs.org>
Date: Sun, 23 Sep 2012 20:59:53 -0400
Links: << >>  << T >>  << A >>
On 9/23/2012 2:44 AM, smileforthecamerahotshot@gmail.com wrote:
> Any help is appreciated. I get errors of the following sort:
>
> "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."
>
> The source for the entire unit in question is as follows:
>
> module tst_1(
>      input rst,
>      input clk,
>      output [7:0] led
> );
>      parameter s_0 = 2'b00;
>      parameter s_1 = 2'b01;
>      parameter s_2 = 2'b10;
>      parameter s_3 = 2'b11;
>
>      reg [1:0] state;
>      reg [7:0] ram[0:15];
>      reg [7:0] regs[0:7];
>
>      initial begin
>          state <= s_0;
>          end
>
>      always @(posedge clk) begin
>          if (rst == 1'b1)
>              state <= s_0;
>          else begin
>              case (state)
>                  s_0: begin
>                      ram[15] <= 8'h00;
>                      state <= s_1;
>                      end
>                  s_1: begin
>                      regs[0] <= ~ram[8];
>                      ram[15][0] <= 1'b1;
>                      ram[15][1] <= 1'b0;
>                      state <= s_2;
>                      end
>                  s_2: begin
>                      ram[7] <= regs[0];
>                      ram[15][2] <= ~regs[0][7];
>                      ram[15][3] <= regs[0][3];
>                      state <= s_3;
>                      end
>                  s_3: begin
>                      ram[8] <= ram[7] ^ ram[15];
>                      state <= s_1;
>                      end
>                  default:
>                      state <= s_0;
>                  endcase
>              end
>          end
>      assign led = regs[0];
> endmodule
>
> For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?
>
Perhaps ram[15][1] is never driven to a value other than zero and has
been "replaced by logic."  What tools are you using, and what version?
I have seen a lot of bogus multi-source messages from Xilinx XST
especially when using arrays and loops.  Theoretically any number
of assignments in the same process should never create a multi-source
error.

-- Gabor

Article: 154293
Subject: Re: multi-source errors
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 24 Sep 2012 02:08:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
smileforthecamerahotshot@gmail.com wrote:
> Any help is appreciated. I get errors of the following sort:

> "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this 
> signal is connected to multiple drivers."


It isn't so obvious to me how to read this.

It seems that it should depend on what is available
as RAM resources.

> The source for the entire unit in question is as follows:

> module tst_1(
>    input rst,
>    input clk,
>    output [7:0] led
> );
>    parameter s_0 = 2'b00;
>    parameter s_1 = 2'b01;
>    parameter s_2 = 2'b10;
>    parameter s_3 = 2'b11;

>    reg [1:0] state;
>    reg [7:0] ram[0:15]; 
>    reg [7:0] regs[0:7];

>    initial begin
>        state <= s_0;
>        end

>    always @(posedge clk) begin
>        if (rst == 1'b1)
>            state <= s_0;
>        else begin
>            case (state)
>                s_0: begin
>                    ram[15] <= 8'h00;

OK, being inside the always @(posedge clk) this is a synchronous RAM.

Personally, I do like writing state machines with the state
logic inside, but some tell me that the state selection and
state action should be separate blocks. Normally I don't believe
the difference matters, but it isn't so obvious to me in the
case of ram.

>                    state <= s_1;
>                    end
>                s_1: begin
>                    regs[0] <= ~ram[8];
>                    ram[15][0] <= 1'b1;
>                    ram[15][1] <= 1'b0;

Since only two bits of ram are being changed, this requires
either separate RAMs or separate write enable bits.

>                    state <= s_2;
>                    end
>                s_2: begin
>                    ram[7] <= regs[0];
>                    ram[15][2] <= ~regs[0][7];
>                    ram[15][3] <= regs[0][3];

Now you change both ram[7] and ram[15] in the same state,
so it requires dual port write access. That is fine, but
is much less common than dual port read.

>                    state <= s_3;
>                    end
>                s_3: begin
>                    ram[8] <= ram[7] ^ ram[15];

In this case, dual port read and separate write port at the same time.

>                    state <= s_1;
>                    end
>                default:
>                    state <= s_0;
>                endcase
>            end
>        end
>    assign led = regs[0];
> endmodule

Maybe it doesn't have anything to do with the problem, but are
you sure that the target architecture supports RAM with two read
and two write ports?

-- glen

Article: 154294
Subject: Re: multi-source errors
From: smileforthecamerahotshot@gmail.com
Date: Sun, 23 Sep 2012 19:42:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, September 23, 2012 5:58:45 PM UTC-7, Gabor wrote:
>=20
> > Any help is appreciated. I get errors of the following sort:
>=20
> >
>=20
> > "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is co=
nnected to multiple drivers."
>=20
> >
>=20
> > The source for the entire unit in question is as follows:
>=20
> >
>=20
> > module tst_1(
>=20
> >      input rst,
>=20
> >      input clk,
>=20
> >      output [7:0] led
>=20
> > );
>=20
> >      parameter s_0 =3D 2'b00;
>=20
> >      parameter s_1 =3D 2'b01;
>=20
> >      parameter s_2 =3D 2'b10;
>=20
> >      parameter s_3 =3D 2'b11;
>=20
> >
>=20
> >      reg [1:0] state;
>=20
> >      reg [7:0] ram[0:15];
>=20
> >      reg [7:0] regs[0:7];
>=20
> >
>=20
> >      initial begin
>=20
> >          state <=3D s_0;
>=20
> >          end
>=20
> >
>=20
> >      always @(posedge clk) begin
>=20
> >          if (rst =3D=3D 1'b1)
>=20
> >              state <=3D s_0;
>=20
> >          else begin
>=20
> >              case (state)
>=20
> >                  s_0: begin
>=20
> >                      ram[15] <=3D 8'h00;
>=20
> >                      state <=3D s_1;
>=20
> >                      end
>=20
> >                  s_1: begin
>=20
> >                      regs[0] <=3D ~ram[8];
>=20
> >                      ram[15][0] <=3D 1'b1;
>=20
> >                      ram[15][1] <=3D 1'b0;
>=20
> >                      state <=3D s_2;
>=20
> >                      end
>=20
> >                  s_2: begin
>=20
> >                      ram[7] <=3D regs[0];
>=20
> >                      ram[15][2] <=3D ~regs[0][7];
>=20
> >                      ram[15][3] <=3D regs[0][3];
>=20
> >                      state <=3D s_3;
>=20
> >                      end
>=20
> >                  s_3: begin
>=20
> >                      ram[8] <=3D ram[7] ^ ram[15];
>=20
> >                      state <=3D s_1;
>=20
> >                      end
>=20
> >                  default:
>=20
> >                      state <=3D s_0;
>=20
> >                  endcase
>=20
> >              end
>=20
> >          end
>=20
> >      assign led =3D regs[0];
>=20
> > endmodule
>=20
> >
>=20
> > For the interested, I get multi-source errors on ram[15][3], ram[15][2]=
, and ram[15][0]... but not ram[15][1]. Since the signals in question are a=
ll driven from different states within the same FSM, I am not sure why this=
 is considered multiple drivers. I am sure this is something obvious to the=
 well-informed. Any ideas?
>=20
> >
>=20
> Perhaps ram[15][1] is never driven to a value other than zero and has
>=20
> been "replaced by logic."  What tools are you using, and what version?
>=20
> I have seen a lot of bogus multi-source messages from Xilinx XST
>=20
> especially when using arrays and loops.  Theoretically any number
>=20
> of assignments in the same process should never create a multi-source
>=20
> error.
>=20
>=20
>=20
> -- Gabor
I am using Xilinx ISE WebPACK v12.4 (nt64). I also tried this using ISE Web=
PACK 9.2i 32-bit and get the same errors. I have tried targeting an XC3S500=
E and an XC3S1600E. One thing that I noticed is that if I change the s_0 st=
ate to do this "ram[15][7:0] <=3D 8'h00;" instead of this "ram[15] <=3D 8'h=
00;" then I get no errors. I don't understand this.

Article: 154295
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Mon, 24 Sep 2012 01:09:35 -0500
Links: << >>  << T >>  << A >>

>
>How are you going to get data into your CPLD at that rate?  Parallel?  
>Some other serial interface that also needs to run at 35MHz or more?
>
>Your feasibility may break up on other rocks than whether the CPLD is up 
>to it.
>
>Having said that -- to my beginner's eyes a parallel in, serial out, 
>35MHz SPI should be doable with a part like that.
>
>-- 
>Tim Wescott
>Control system and signal processing consulting
>www.wescottdesign.com
>

I want to feed data in parallel (8bit) to CPLD, buffer it for about 100
bytes, and then start to drive SPI Out. I am some how concerned about the
speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
-10C(means 10nsec delay for IO routs), does this delay impose any problem?
Since I want to drive the CPLD with 100MHZ oscillator clk input, and by clk
dividing generate a 50 or 40MHz clk for SPI.
tnx for any helpful comments :)
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154296
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Mon, 24 Sep 2012 11:16:11 +0200
Links: << >>  << T >>  << A >>
On 09/24/2012 08:09 AM, nba83 wrote:

> I want to feed data in parallel (8bit) to CPLD, buffer it for about 100
> bytes, and then start to drive SPI Out. I am some how concerned about the
> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
> -10C(means 10nsec delay for IO routs), does this delay impose any problem?
> Since I want to drive the CPLD with 100MHZ oscillator clk input, and by clk
> dividing generate a 50 or 40MHz clk for SPI.
> tnx for any helpful comments :)

The problem isn't going to be the speed, but where the CPLD is going to 
store the 100 bytes. The XC95144XL only has 144 bits of storage total.


Article: 154297
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Mon, 24 Sep 2012 06:00:15 -0500
Links: << >>  << T >>  << A >>
>On 09/24/2012 08:09 AM, nba83 wrote:
>
>> I want to feed data in parallel (8bit) to CPLD, buffer it for about 100
>> bytes, and then start to drive SPI Out. I am some how concerned about
the
>> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
>> -10C(means 10nsec delay for IO routs), does this delay impose any
problem?
>> Since I want to drive the CPLD with 100MHZ oscillator clk input, and by
clk
>> dividing generate a 50 or 40MHz clk for SPI.
>> tnx for any helpful comments :)
>
>The problem isn't going to be the speed, but where the CPLD is going to 
>store the 100 bytes. The XC95144XL only has 144 bits of storage total.
>
>

I have implemented a 1k byte dual port ram in this cpld logic  in xilinx
ise, but i havn't tested it yet. I have not added the DAC driver to it yet,
i'm not sure if this cpld is enough for these modules. here is the
implementation for RAM:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity dpram_4x2045 is
    Port ( DIN : in std_logic_vector(7 downto 0);
           RE_ADDRESS : in std_logic_vector(10 downto 0);
			  wr_address :in std_logic_vector(10 downto 0);
           CLCK_wr : in std_logic;
           CLCK_re : in std_logic;
           We : in std_logic;
           Re : in std_logic;
           dout : out std_logic_vector(7 downto 0));
end dpram_4x2045 ;

architecture Behavioral of dpram_4x2045  is
type my_data is array (0 to 2048)of std_logic_vector(7 downto 0) ;
signal rom: my_data;
begin

process (clck_wr)--write
begin
   if (clck_wr'event and clck_wr = '0') then
				if (we = '1') then
            rom(conv_integer(WR_address)) <= din;
           
          end if;
   end if;
end process;

process (clck_re)--read
begin
   if (clck_re'event and clck_re = '1') then ---e
         if (Re = '1') then
             dout<=rom(conv_integer(RE_address));
         end if;
    
   end if;
end process;

end Behavioral;

and the other module will receive bytes from parallel port and write it in
buffer, after writing 100 bytes, spi out module is enabled. and send out
data bytes	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154298
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 24 Sep 2012 09:20:37 -0700
Links: << >>  << T >>  << A >>
On Mon, 24 Sep 2012 06:00:15 -0500
"nba83" <3224@embeddedrelated> wrote:

> >On 09/24/2012 08:09 AM, nba83 wrote:
> >
> >> I want to feed data in parallel (8bit) to CPLD, buffer it for about 100
> >> bytes, and then start to drive SPI Out. I am some how concerned about
> the
> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
> >> -10C(means 10nsec delay for IO routs), does this delay impose any
> problem?
> >> Since I want to drive the CPLD with 100MHZ oscillator clk input, and by
> clk
> >> dividing generate a 50 or 40MHz clk for SPI.
> >> tnx for any helpful comments :)
> >
> >The problem isn't going to be the speed, but where the CPLD is going to 
> >store the 100 bytes. The XC95144XL only has 144 bits of storage total.
> >
> >
> 
> I have implemented a 1k byte dual port ram in this cpld logic  in xilinx
> ise, but i havn't tested it yet. I have not added the DAC driver to it yet,
> i'm not sure if this cpld is enough for these modules. here is the
> implementation for RAM:
> 

You've written behavioral VHDL that describes a dual-port
block RAM. That's lovely and all, but have you checked the CPLD
datasheet and confirmed that there is a block RAM resource on the chip
that will do that?  You could also write VHDL describing a unicorn, but
you'd be hard pressed to make it pass synthesis.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154299
Subject: Re: Error while running implementation through unix command line
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 24 Sep 2012 09:30:00 -0700
Links: << >>  << T >>  << A >>
On Sun, 23 Sep 2012 13:03:13 -0500
"gaurav3110" <3677@embeddedrelated> wrote:

> 
> Hello,
> 
>  
> 
> I am new to Xilinx and bash scripting. I am using Xilinx 13.4. I am trying
> to run implementation(ngdbuild, map, par etc) to create the bit file
> through a bash script, but I am getting an error. Following is the snippet
> of my error :-
> 
> Running synthesis...
> 
> bash -c "cd synthesis; ./synthesis.sh"
> xst -ifn system_xst.scr -intstyle silent
> Running XST synthesis ...
> PMSPEC -- Overriding Xilinx file
> </tools/Xilinx/13.4/ISE_DS/EDK/virtex5/data/virtex5.acd> with local file
> </tools/Xilinx/13.4/ISE_DS/ISE/virtex5/data/virtex5.acd>
> XST completed
> error status of previous command:0
> => Starting xst: Xst log file is: no_file.syr
> Using xst file - no_file.xst
> 

Yeah, it's looking for some reason for an XST script file called
no_file.xst, and can't find it.  The problem is probably in your
system_xst.scr file (which I wouldn't swear up and down is allowed to
have an extension other than .xst)

I use a Makefile scripted flow for all my Xilinx projects.  On the
most recent one I'm working on, my command line call is:
  xst -ifn top_level_gen.xst -ofn 28C940A-xst.log

And this is my top_level_gen.xst:
  set -xsthdpdir ./_xst
  set -tmpdir ./_xst/tmp
  run
  -resource_sharing NO
  -keep_hierarchy SOFT
  -glob_opt allclocknets
  -opt_level 2
  -opt_mode speed
  -rtlview yes
  -bufg 0
  -ifn 28C940A.prj
  -ofn 28C940A
  -top top_level
  -iobuf YES
  -uc synth/28A940.xcf
  -p xc3s1500-4-fg456
  -generics {REV='A' CODE=28940 STAMP=1347396632}


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.



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