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 116550

Article: 116550
Subject: Heatsink on FPGA?
From: jean-baptiste.nouvel@jdsu.com
Date: 12 Mar 2007 10:04:30 -0700
Links: << >>  << T >>  << A >>
Hi,

Anybody has experience with heatsinks on FPGAs?

In the V5 documentation, Xilinx says the heatsink can be glued to the
FPGA but that it
is safer to screw it to the board to avoid mechanical contraints to
the FPGA
ball when under vibrations.

But then the screws take some space on the board that we can't really
afford...
This would be at the expense of signal integrity (longer PCB
tracks...).

Any feedback welcome :o)

Many thanks,
Jean-Baptiste.


Article: 116551
Subject: Re: PAL
From: "Peter Alfke" <peter@xilinx.com>
Date: 12 Mar 2007 10:44:21 -0700
Links: << >>  << T >>  << A >>
On Mar 12, 8:07 am, "Peter Soegaard" <p.soega...@tiscali.dk> wrote:
> Hi,
>
> I'm working on colorbar generator VHDL code from Xilinx (file name cb_eg1.vhd, from Xapp514, Chapter 16). The format is NTSC. Is there anyone who has modified the code to PAL format? I've inserted the right line numbers and regions for the colorbars. However the V-sync. signal is not as it should be.
>
> Regards Peter Soegaard

Peter,
this is what I learned from our Applications folks:

"The cb_eg1.vhd design is NTSC specific, but there is a PAL video test
pattern generator included in XAPP514 chapter 16. The vidgen.v file
includes ROM init files for either NTSC or PAL."

Peter Alfke, Xilinx


Article: 116552
Subject: Re: Initialization of arrays in Verilog
From: "Till Wollenberg" <till@deadspam.com>
Date: Mon, 12 Mar 2007 19:37:38 +0100
Links: << >>  << T >>  << A >>
Hi!

* "Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> Till Wollenberg <till@deadspam.com> wrote:
> ...
> > But now I have to synthesize the design using ISE 7.1i...
> 
> Tell us why you have to synthesize with 7.1i

Updating to 8.1i would surely solve my problem but I don't have
appropriate permissions and so I'm stuck with 7.1i at least for
the next days.

I thought that there *must* be a way to initialize arrays with
7.1i. Googling a bit I found some discussion threads exactly covering
my problem but they all end up without a solution.

Till.

-- 
real e-mail: wollenberg (at) web (dot) de


Article: 116553
Subject: Re: odd warning in Xilinx ISE webpack
From: "Andy Peters" <google@latke.net>
Date: 12 Mar 2007 11:46:17 -0700
Links: << >>  << T >>  << A >>
On Mar 8, 1:39 am, Steve Battazzo <thesteveman_i...@yahoo.co.jp>
wrote:
> At the XST-synthesize stage, I'm getting this weird warning:
> "Property use_dsp48" is not applicable for this technology.
> I don't have anything in my code that I know of that calls for any such
> thing.. it doesn't affect the program actually running on my board, but
> I'm curious anyway.

I'm getting the exact same pointless warning for a Spartan 3E design
that's all VHDL.  I've gone through all of the docs looking for where
it's set and all that, and I came up with nothing.  Apparently, it
defaults to "no" (which is reasonable, because S3E doesn't have DSP48
blocks) but since the tool has a default for that attribute, it's
still applied, and you get the warning.  The tools should be smart
enough to know this.  It would be reasonable to get a warning if you
actually set the use_dsp48="yes" attribute for S3E.

Xilinx' notion of "what's a Warning, what's an Info, and what should
be ignored" is often perverse.  Here's an example (and I've opened a
support case about it):

VHDL has the "open" keyword, which you use on a port map to indicate
that a port is not being used.  (You use this a lot when instantiating
DCMs,)  So when you use "open," you're explicitly telling the tools:
"I know I am not using this port."  However, you get a nice, big
yellow "WARNING!" triangle in your synthesis report, and a message
saying, "Unconnected output port 'foo' of component 'bar.' "  Yeah, I
know this, and I used the keyword "open" to tell you to not tell me
that the port is not connected!

On the other hand, I reused some old code that was supposed to infer a
BRAM, and the inference didn't work and instead the tool built the
memory out of slices and ate up all of the resources in my chip.  I
was kind of suprised when the mapper failed, saying that I was trying
to use 200% of the slices.  I went back to the synthesis report, and
noticed an innocuous "Info:" line with a message about "due to
asynchronous read, described memory could not be used with BRAMs, so
it will be put into distributed RAM instead."

Seems to me that something that could affect the size and performance
of a design should be a WARNING, and something where the tools are
told "I know what I'm doing" shouldn't even be an Info!

-a


Article: 116554
Subject: Re: Design report does not show BRAM usage
From: "Andy Peters" <google@latke.net>
Date: 12 Mar 2007 11:55:16 -0700
Links: << >>  << T >>  << A >>
On Mar 11, 7:23 am, "Bhanu Chandra" <vbh...@gmail.com> wrote:
> Hi all,
>
> I have created a peripheral and attached it to the OPB bus. This
> peripheral is composed of a controller and also BRAM block directly
> attached to it. There is no bus between the controller and the BRAM
> block. The BRAM block is a 32KB block which is composed of 16 RAMB16
> primitives.
>
> I have synthesized the peripheral which happens with out a glitch and
> then generated the netlist followed by the bitstream generation. All
> this happens but then the design report does not show that the
> peripheral is using the RAMB16 primitive. Someone please tell me what
> is wrong here.
>
> Also is there any example code which could guide me about how to use
> RAMB16's.
>
> I am using XPS 8.2i and ISE 8.2i and a virtex-4 board.

Did you infer the BRAMs or did you instantiate them?

If the former, carefully check your synthesis report.  Unfortunately,
the tools will give you a polite Info: if your code did not properly
infer a BRAM.

-a


Article: 116555
Subject: Re: Estimating number of FPGAs needed for an application
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 12 Mar 2007 11:06:20 -0800
Links: << >>  << T >>  << A >>
comp.arch.fpga wrote:
(snip)

> For DNA matching you might have 2-bit or 4-bit data types.

For dynamic programming algorithms, the favorite way to do DNA
matching, it is usual to do 16 bit fixed point arithmetic.

-- glen


Article: 116556
Subject: Re: Estimating number of FPGAs needed for an application
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 12 Mar 2007 11:18:55 -0800
Links: << >>  << T >>  << A >>
rbblasco@gmail.com wrote:

> I'm absolutely new to FPGAs, in fact my work is much more related with
> the SW than with the HW, so I need to solve a problem that ideally I
> was not targeted to.

> The issue is this: I have to estimate (roughly) the number of FPGAs
> needed to support a typical signal processing algorithm, steps are as
> follows, always in single-precision:

> 1.16k complex samples FFT
> 2. 16k complex vector multiplication
> 3. 16k complex samples IFFT
> 4. 16k complex vector multiplication
> 5. 16 k complex vector sum

> The idea is to know how many FPGAs will cover this kind of processing
> in a given time, to compare with different types of processors. Por
> the later, it is really easy just counting number of operations in
> GFLOPs, but with hardware devices I am getting a lot of trouble, since
> I don't have a clear understanding on what should I count.

First, floating point tends to be a lot bigger on FPGAs than fixed
point, especially floating point addition.  If you can get away with
fixed point, even if the actual width is somewhat larger, it is probably
worth doing.

Also, you can't just count 'FPGA', but you have to take into account
the size of the different FPGAs, even from the same product family.

I like systolic array processors, which usually work well for this
type of problem.  The thought process for hardware implementations,
especially good pipelined ones, is somewhat different than for software
implementations.   Usually hardware implementations are used when 
software isn't fast enough, so you need to know how fast it has to go.

There is a tradeoff between time and size, but it isn't linear enough
to quote without more details.

-- glen


Article: 116557
Subject: Re: Design report does not show BRAM usage
From: "John McCaskill" <junkmail@fastertechnology.com>
Date: 12 Mar 2007 12:37:21 -0700
Links: << >>  << T >>  << A >>
On Mar 12, 5:32 am, "Bhanu Chandra" <vbh...@gmail.com> wrote:
> On Mar 12, 4:04 pm, "Bhanu Chandra" <vbh...@gmail.com> wrote:
>
>
>
> > This is what I have, please tell me if something seems wrong here
> > since this is the code that does not make BRAM usage appear in the
> > design report.
>
> > RAMB16_S36_S36 CAC1 (.DOA (DOA_CAC1),
> >                     .DOB (DOB_CAC1),
> >                     .DOPA (DOPA_CAC1),
> >                     .DOPB (DOPB_CAC1),
> >                     .ADDRA (ADDRA_CAC1),
> >                     .ADDRB (ADDRB_CAC1),
> >                     .CLKA (Bus2IP_Clk),
> >                     .CLKB (Bus2IP_Clk),
> >                     .DIA (DIA_CAC1),
> >                     .DIB (DIB_CAC1),
> >                     .DIPA (DIPA_CAC1),
> >                     .DIPB (DIPB_CAC1),
> >                     .ENA (ENA_CAC1),
> >                     .ENB (ENB_CAC1),
> >                     .SSRA (1'b0),
> >                     .SSRB (1'b0),
> >                     .WEA (WEA_CAC1),
> >                     .WEB (WEB_CAC1));
>
> > defparam CAC1.INIT_00 =
> > 256'h0000000000000000000000000000000000000000000000000000000000000000;
>
> > Thanks,
> > Bhanu
>
> > Uwe Bonnes wrote:
> > > Bhanu Chandra <vbh...@gmail.com> wrote:
>
> > > > Could someone please share a sample code which instantiates the BRAM
> > > > blocks?
>
> > > Here I use one block as 8/32 Bit:
> > >    /*
> > >     * Tie unused data/address High (ug331, p.155
> > >     * Readout data is in upper portion
> > >     */
> > >     RAMB16_S9_S36 ram1(
> > >                   .DOA(scaler_dout),
> > >                   .DOB(scaler_read_data),
> > >                   .DOPA(),
> > >                   .DOPB(),
> > >                   .ADDRA({{3{1'b1}},byteaddress[7:0]}),
> > >                   .ADDRB({{2{1'b1}},scaler_addr}),
> > >                   .CLKA(clk),
> > >                   .CLKB(clk),
> > >                   .DIA({8{1'b1}}),
> > >                   .DIB(scaler_write_data),
> > >                   .DIPA(4'b1),
> > >                   .DIPB(4'b1),
> > >                   .ENA((address == `SCALER)),
> > >                   .ENB(scaler_ena),
> > >                   .SSRA(1'b0),
> > >                   .SSRB(scaler_rst_cycle),
> > >                   .WEA(1'b0),
> > >                   .WEB(scaler_wea)
> > >                   );
>
> > > The 8-bit side only reads the ram
>
> > > --
> > > Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de
>
> > > Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>
> Seems like this is not the issue. What happened is that I had created
> a .h file within which I was doing all the instantiation. Possible
> that it was not including the file? I am getting a little confused
> here, XPS does not seem to support include directive of verilog. Has
> anyone tried it? I have now included the instantiation also in the
> main user_logic file, it now fails to resolve a function. Please
> mention if someone has in the past experienced the same problems.
>
> Thanks,
> Bhanu



I have Verilog code that uses include files, and it works with ISE. I
stopped using them quite a while back because EDK lacks a method to
tell it where to look for include files, and ISE just assumes that
they are in its working directory unless told other wise.

Regards,

John McCaskill
www.fastertechnology.com


Article: 116558
Subject: Re: Addressing scheme in Block RAM
From: "Paul" <pauljbennett@gmail.com>
Date: 12 Mar 2007 13:16:17 -0700
Links: << >>  << T >>  << A >>
Check the Xilinx documentation.  There are exhaustive descriptions of
what addresses to what when you're using dual ports with differing
aspect ratios.



On Mar 10, 10:21 pm, "Peter Alfke" <a...@sbcglobal.net> wrote:
> It looks to me that you use the second bit position in the upper
> nibble (you call it 20) as your least significant bit... I am sure
> this is just an address-bit ordering problem.
> Please tell us when you got this straightened out.
> Peter Alfke, from home
> ==========
> On Mar 9, 10:44 pm, "Venu" <get2v...@gmail.com> wrote:
>
>
>
> > Hi People,
>
> > I have generated a duap port RAM using a Xilinx Core generator .
> > Port A is 32 x 32 and Port B is 8 x 128
>
> > The 32 bit port , Port A , is interpreting the addresses in the row
> > order
> > 00
> > 01
> > 02
> > .
> > .
> > .
> > 1F
>
> > I had expected the 8 bit port to also interpret the addresses in the
> > row order. I have done the simulation of the DPRAM and this was it
> > responded as expected.
>
> > 03    02    01    00
> > 07    06    05    04
> > .........................
> > 7F    7E    7D   7C
>
> > But now comes the weird part . I implemented my design on a Xilinx
> > Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in
> > the column order ,. I have observed this using debug data as well as
> > using Chip Scope Pro,  i.e.
>
> > 60    40    20    00
> > 61    41    21    01
> > 62    42    22    02
> > 63    43    23    03
> > .
> > 7F    5F    3F   1F
>
> > Are there any synthesis constraints that can prevent this from
> > happening . All the documents and application notes say that the 8 bit
> > port also should be addressed in the row ordering fashion. Could any
> > one suggest why I might be having this problem
>
> > Thank You
> > Venu- Hide quoted text -
>
> - Show quoted text -



Article: 116559
Subject: Re: Xilin X-Fest Lunacy
From: "Peter Alfke" <peter@xilinx.com>
Date: 12 Mar 2007 13:22:24 -0700
Links: << >>  << T >>  << A >>
Poof ! It's gone, at least for the European registration.
No more reason to delay your sign-up...
Peter Alfke

On Mar 12, 7:37 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> I just stated in the comments box that I do not agree.
> In germany the hand written text should supercede the check box in a
> contract.
>
> Kolja Sulimma
>
> On 12 Mrz., 15:32, "Peter Alfke" <a...@sbcglobal.net> wrote:
>
> > Let's see how fast Avnet can react.
> > The problem has been brought to their attention.
> > The clock is ticking...
> > Peter Alfke



Article: 116560
Subject: 3.3V tolerant Virtex-4 JTAG Configuration
From: "Dale" <dale.prather@gmail.com>
Date: 12 Mar 2007 14:05:11 -0700
Links: << >>  << T >>  << A >>
Hello,
I've been looking through Xilinx's website for quite some time now for
information on using 3.3V to configure a Virtex-4 through the JTAG
interface.  Is there anything equivalent to the link below for the
Virtex 4?  That's a very good document for the Spartan 3 and I'm
hoping to find something similar for the V4.

http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=20477

Thanks,
Dale


Article: 116561
Subject: Re: 3.3V tolerant Virtex-4 JTAG Configuration
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 12 Mar 2007 14:20:10 -0700
Links: << >>  << T >>  << A >>
Dale,

This also applies to:

V4,
V5
S3A
S3E

Austin

Article: 116562
Subject: Re: Dual edge detection
From: "Peter Alfke" <peter@xilinx.com>
Date: 12 Mar 2007 15:44:19 -0700
Links: << >>  << T >>  << A >>
Wouldn't it be nice to see this as a schematic, and evaluate it in 5
minutes max...
Peter Alfke, schematosaurus.

On Mar 12, 7:29 am, "Gabor" <g...@alacron.com> wrote:
> On Mar 12, 4:40 am, "ALu...@web.de" <ALu...@web.de> wrote:
>
>
>
> > Hi newsgroup,
>
> > As shown in the VHDL code I am feeding two flip flop chains
> > with the same input. The chains use complementary clocks (200Mhz).
>
> > In the process "rise_fall" I do some combinational logic
> > to detect rising and falling of the sampled input.
>
> > Now I want to use one of the combinational signals as a clock
> > in a process "clksel" to sample the second combinationl signal.
>
> > Speaking in terms of functional simulation the function
> > of the hardware description is the following:
> > The signal which gets active first
> > is used for ClockSel.
>
> > The output ClockSel is then used to feed a DCS module.
>
> > The problem I see in this hardware description is that
> > the clock in the process "clksel" is a gated clock.
>
> > What is your opinion about the desription ? How can
> > I modify it to make it synthesizable ? Is there some
> > need for additional constraints ?
>
> > library ieee;
> > use ieee.std_logic_1164.all;
>
> > entity ana is
> > port( Reset    : in  std_logic;
> >       Clk      : in  std_logic;
> >       DataIn   : in  std_logic;
> >       ClockSel : out std_logic
> >     );
> > end ana;
>
> > architecture arch_ana of ana is
>
> > signal r_p1, r_p2, r_p3 : std_logic;
> > signal f_p1, r_p2, r_p3 : std_logic;
>
> > signal trig_rise, trig_fall : std_logic;
>
> > begin
>
> > ------------------------------------
> >  sync_redge: process(Reset, Clk)
> >  begin
> >    if Reset='1' then
> >       r_p1 <= '0';
> >       r_p2 <= '0';
> >       r_p3 <= '0';
>
> >    elsif rising_edge(Clk) then
> >       r_p1 <= DataIn;
> >       r_p2 <= r_p1;
> >       r_p3 <= r_p2;
>
> >    end if;
> >  end process sync_redge;
>
> > ------------------------------------
> >  sync_fedge: process(Reset, Clk)
> >  begin
> >    if Reset='1' then
> >       f_p1 <= '0';
> >       f_p2 <= '0';
> >       f_p3 <= '0';
>
> >    elsif falling_edge(Clk) then
> >       f_p1 <= DataIn;
> >       f_p2 <= f_p1;
> >       f_p3 <= f_p2;
>
> >    end if;
> >  end process sync_fedge;
>
> > ------------------------------------
> >  rise_fall: process(r_p2, r_p3,
> >                     f_p2, f_p3)
> >  begin
>
> >    trig_rise <= ((not r_p3) AND r_p2);
> >    trig_fall <= ((not_f_p3) AND f_p2);
>
> >  end process rise_fall;
>
> > ------------------------------------
> > -- ?????????????????????????????????
> >  clksel: process(Reset, trig_fall)
> >  begin
> >    if Reset='1' then
> >       ClockSel <= '0';
>
> >    elsif rising_edge(trig_fall) then
> >       ClockSel <= trig_rise;
> >    end if;
> >  end process clksel;
>
> > end arch_ana;
>
> Why do you need to make the clksel process asynchronous to Clk?
> It would seem to me that trig_fall can only change as a result
> of a negative edge of Clk.  So unless you really want a lot of
> delay from the negative clock edge to the ClockSel signal, I
> would think you'd just use the falling edge of Clk and the
> f_p1 and f_p2 signals as clock enables.  Or did you do this to
> avoid a clock delay?  Is DataIn asynchronous to Clk?



Article: 116563
Subject: Re: Dual edge detection
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 12 Mar 2007 16:04:55 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Wouldn't it be nice to see this as a schematic, and evaluate it in 5
> minutes max...

Wouldn't hurt.
Usenet is a very poor simulator.


         -- Mike Treseler

Article: 116564
Subject: Re: Dual edge detection
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 12 Mar 2007 17:35:59 -0700
Links: << >>  << T >>  << A >>
ALuPin,

Rather than using two chains on two different edges, how about changing both 
input phases to one domain?  The clocking is much easier and the delay 
penalty is only a half clock (2.5 ns in your case).  When the data comes 
together in the common domain, an edge at the front of this domain occurs if 
the transition is in the two sampled bits: current and half-delayed; an edge 
(half-cycle earlier) at the start of the delayed domain is indicated by a 
data change between the previous cycle's normal sample and the current 
cycle's delayed sample.  There's two phases of algorithm in one domain 
rather than two phase domains for one algorithm.  You could keep all 
processing in this common time domain until you're ready to interface back 
to the external world where you can directly apply DDR IOB registers. 
Clean, friendly.

The technique can push internal DDR at full Xilinx global clock rates - 330 
MHz for the Spartan 3E for 660 Mb/s DDR processing - by using a latch rather 
than a register to transfer the delayed data (with appropriately altered 
timing constraints) if the time between opposite clock edges is too small 
for Tcko+Tnet+Tsu in a simple register delay.

- John_H


<ALuPin@web.de> wrote in message 
news:1173692457.336947.298090@h3g2000cwc.googlegroups.com...
> Hi newsgroup,
>
> As shown in the VHDL code I am feeding two flip flop chains
> with the same input. The chains use complementary clocks (200Mhz).
>
>
> In the process "rise_fall" I do some combinational logic
> to detect rising and falling of the sampled input.
>
>
> Now I want to use one of the combinational signals as a clock
> in a process "clksel" to sample the second combinationl signal.
>
>
> Speaking in terms of functional simulation the function
> of the hardware description is the following:
> The signal which gets active first
> is used for ClockSel.
>
>
> The output ClockSel is then used to feed a DCS module.
>
>
> The problem I see in this hardware description is that
> the clock in the process "clksel" is a gated clock.
>
>
> What is your opinion about the desription ? How can
> I modify it to make it synthesizable ? Is there some
> need for additional constraints ?
>
> library ieee;
> use ieee.std_logic_1164.all;
>
>
> entity ana is
> port( Reset    : in  std_logic;
>      Clk      : in  std_logic;
>      DataIn   : in  std_logic;
>      ClockSel : out std_logic
>    );
> end ana;
>
>
> architecture arch_ana of ana is
>
>
> signal r_p1, r_p2, r_p3 : std_logic;
> signal f_p1, r_p2, r_p3 : std_logic;
>
>
> signal trig_rise, trig_fall : std_logic;
>
>
> begin
>
>
> ------------------------------------
> sync_redge: process(Reset, Clk)
> begin
>   if Reset='1' then
>      r_p1 <= '0';
>      r_p2 <= '0';
>      r_p3 <= '0';
>
>
>   elsif rising_edge(Clk) then
>      r_p1 <= DataIn;
>      r_p2 <= r_p1;
>      r_p3 <= r_p2;
>
>
>   end if;
> end process sync_redge;
>
>
> ------------------------------------
> sync_fedge: process(Reset, Clk)
> begin
>   if Reset='1' then
>      f_p1 <= '0';
>      f_p2 <= '0';
>      f_p3 <= '0';
>
>
>   elsif falling_edge(Clk) then
>      f_p1 <= DataIn;
>      f_p2 <= f_p1;
>      f_p3 <= f_p2;
>
>
>   end if;
> end process sync_fedge;
>
>
> ------------------------------------
> rise_fall: process(r_p2, r_p3,
>                    f_p2, f_p3)
> begin
>
>
>   trig_rise <= ((not r_p3) AND r_p2);
>   trig_fall <= ((not_f_p3) AND f_p2);
>
>
> end process rise_fall;
>
>
> ------------------------------------
> -- ?????????????????????????????????
> clksel: process(Reset, trig_fall)
> begin
>   if Reset='1' then
>      ClockSel <= '0';
>
>
>   elsif rising_edge(trig_fall) then
>      ClockSel <= trig_rise;
>   end if;
> end process clksel;
>
>
> end arch_ana; 



Article: 116565
Subject: Re: Heatsink on FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 12 Mar 2007 22:00:34 -0400
Links: << >>  << T >>  << A >>
jean-baptiste.nouvel@jdsu.com wrote:

> Hi,
> 
> Anybody has experience with heatsinks on FPGAs?
> 
> In the V5 documentation, Xilinx says the heatsink can be glued to the
> FPGA but that it
> is safer to screw it to the board to avoid mechanical contraints to
> the FPGA
> ball when under vibrations.
> 
> But then the screws take some space on the board that we can't really
> afford...
> This would be at the expense of signal integrity (longer PCB
> tracks...).
> 
> Any feedback welcome :o)
> 
> Many thanks,
> Jean-Baptiste.
> 

I've been putting heatsinks on FPGAs for quite a while, including 
heatsinks with fans on them.  Gluing is fine for in the lab, but if it 
is going into the field, you'll want a better mechanical connection to 
the FPGA if the heat sink has any mass to it.  That can be done with 
screws to the board, or with some arrangement of springs on the chassis 
if your mechanical arrangement allows it. You could also fabricate a 
hold-down bracket that screws to the board, thereby only taking a little 
bit of board real-estate at two points (one we did had a bracket that 
went diagonally across the heatsink and held to the board with two screws).

Article: 116566
Subject: Re: odd warning in Xilinx ISE webpack
From: "Brian Davis" <brimdavis@aol.com>
Date: 12 Mar 2007 19:31:50 -0700
Links: << >>  << T >>  << A >>
 I've recently been trying to synthesize some well simulated
VHDL code from years past, that works fine in XST 6.x, but
fails horribly when using XST 9.1SP2

I've seen some of these {same} annoyances/problems so far:
 1) spurious DSP48 warnings
 2) 'open' keyword problems
 3) 'alias' bugs cause huge chunks of logic to be "optimized" away

Details below.

Brian

------------------------

1) spurious DSP48 warnings

Andy wrote:
>
> I'm getting the exact same pointless warning for a Spartan 3E
> design that's all VHDL.  I've gone through all of the docs looking
> for where it's set and all that, and I came up with nothing.
>
  I've seen that bogus warning as well, for S3's and S2's
targeted in 9.x; in addition to multiplies, the DSP48's also
are inferred for add/subs in targets having them.

Just for fun, try clicking the "HELP" button in the
synthesis/properties dialog box of 9.1SP2 XST :
"
" DSP Utilization Ratio (Advanced) (Virtex-4, Virtex-5, and
Spartan-3AD only)
"

Hypothetical Question of the Day:

  If the "N" in S3-AN stands for "non-volatile", what might
the "D" in "S3-AD" stand for ;)

------------------------

2) 'open' keyword problems

Andy wrote:
>
> VHDL has the "open" keyword, which you use on a port map to indicate
> that a port is not being used.  (You use this a lot when instantiating
> DCMs,)  So when you use "open," you're explicitly telling the tools:
> "I know I am not using this port."  However, you get a nice, big
> yellow "WARNING!" triangle in your synthesis report, and a message
> saying, "Unconnected output port 'foo' of component 'bar.' "  Yeah, I
> know this, and I used the keyword "open" to tell you to not tell me
> that the port is not connected!
>
 This one gets even worse than the bogus warnings.

 The "open" keyword is _needed_ to use certain primitives like
BUFGMUX, which otherwise error out in PAR due to shared input
routing restrictions when the adjacent BUFGMUX is in use.

 Using "open" on an input is perfectly legal, as long as there
is a default value specified for the component's input port.

 Unfortunately, someone at Xilinx thinks otherwise, having removed
the default values from certain library primitives, rendering
them unusable, and placing the following misinformation in the
latest 9.1 XST user Guide, pp445:
"
" According to the IEEE VHDL specification, input ports cannot be
" left unconnected. As a result, XST always gives an error if an
" input port is not connected; even the open keyword will not
" suffice for an unconnected input port.
"
 Which is just plain wrong.

 Workaround for BUFGMUX:

 LOC them all,then attach each of the unused BUFGMUX inputs,
that formerly were 'open', to the input net that's being used
by the adjacent BUFGMUX.

------------------------

3) 'alias' bugs cause huge chunks of logic to be "optimized" away

 XST 9.x sometimes "optimizes" conditionals using aliases out of
existence, resulting in an ever-growing cascade of logic removal.

 Replacing the aliases with signals fixes the problem.

 This error is consistent in my actual code, but I haven't managed
to reproduce it yet in a simple test case, as it seems related to
something else ( tool settings, constant aggregates in packages, ??? )




Article: 116567
Subject: Re: Heatsink on FPGA?
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 13 Mar 2007 00:35:11 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> jean-baptiste.nouvel@jdsu.com wrote:
> 
>> Hi,
>>
>> Anybody has experience with heatsinks on FPGAs?
>>
>> In the V5 documentation, Xilinx says the heatsink can be glued to the
>> FPGA but that it
>> is safer to screw it to the board to avoid mechanical contraints to
>> the FPGA
>> ball when under vibrations.
>>
>> But then the screws take some space on the board that we can't really
>> afford...
>> This would be at the expense of signal integrity (longer PCB
>> tracks...).
>>
> I've been putting heatsinks on FPGAs for quite a while, including 
> heatsinks with fans on them.  Gluing is fine for in the lab, but if it 
> is going into the field, you'll want a better mechanical connection to 
> the FPGA if the heat sink has any mass to it.  That can be done with 
> screws to the board, or with some arrangement of springs on the chassis 
> if your mechanical arrangement allows it. You could also fabricate a 
> hold-down bracket that screws to the board, thereby only taking a little 
> bit of board real-estate at two points (one we did had a bracket that 
> went diagonally across the heatsink and held to the board with two screws).

Another small heatsing fastening method I have seen is a simple torsion bar hooked into a 
pair of through-hole eyelets placed on opposite sides. PCB real-estate for a pair of these 
is something like 3-4 square milimeters. No screws, easy to service, negligible PCB area 
and the eyelet tabs can be however long as necessary to clear nearby SMT components.

Article: 116568
Subject: Re: Addressing scheme in Block RAM
From: "Venu" <get2venu@gmail.com>
Date: 12 Mar 2007 23:02:18 -0700
Links: << >>  << T >>  << A >>
As suggested by John, I replaced the BRAM generated by Xilinx Core
Generator with a Xilinx Primitive RAMB16_S9_S36. I did not change any
logic surrounding the memory modules. Now my memory is being addressed
in the ROW ORDER fashion. ( i.e. as expected from the Xilinx
Documentation )

I am not sure if the problem is with the address bit ordering ,
because then the error should have shown up in both the
implementations . i.e. with the Core Generator as well as with the
Primitve.

The only problem with using the primitive is that now I am using a
memory block of 1024 x 8 as opposed to the 128 x 8. That is eating up
a lot of the resources which I need in other modules.

Thanks
Venu




Article: 116569
Subject: Re: Initialization of arrays in Verilog
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Tue, 13 Mar 2007 06:27:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2007-03-12, Till Wollenberg <till@deadspam.com> wrote:
> I thought that there *must* be a way to initialize arrays with
> 7.1i. Googling a bit I found some discussion threads exactly covering
> my problem but they all end up without a solution.

You could probably instantiate distributed RAM primitives and then
defining the contents of the ram through defparam.

See for example
http://toolbox.xilinx.com/docsan/3_1i/data/common/lib/chap09/lib09003.htm

Or find it in lib.pdf in your local Xilinx documentation
directory.

The problem is that you don't have vendor neutral HDL code
any longer...

/Andreas

Article: 116570
Subject: Re: Power PC embeded in Virtex II Pro. Could I erase it with a new bitstream?
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Tue, 13 Mar 2007 06:41:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2007-03-12, Pablo <pbantunez@gmail.com> wrote:
> Thanks so much for your help, but I have not understood some answers:
>
> - First of all. I have EDK in a lot of versions so I don`t need to buy
> it again. The problem is that my board doesn`t belong to Xilinx, so I
> can`t use EDK. I have a Virtex II Pro (from Xilinx) pluged in a
> Sundance Board (SMT338: http://www.sundance.com/web/files/productpage.asp?STRFilter=SMT338-VP30-6).
> That is the reason because I don`t use EDK. Correct me please.
>
> - Second. I am very grateful if you could tell me some thing to begin
> learning, because I have no idea of how can I program a simple "hello
> world", or something in C (if I could with Power PC).

Ah, now I understand what you are getting at.

It is possible to use the EDK with this FPGA board but you will have
to do some more work yourself. I have not done so myself however so
I'm not sure of exactly how to do it. However, the documentation at
for example the following page talks about using a custom board:

http://toolbox.xilinx.com/docsan/xilinx8/help/platform_studio/html/ps_p_bsb_selecting_development_board.htm

As a first try I would create a system that only has a serial
port for I/O to minimize the UCF-file editing. (Well, a clock
and a reset signal is good to have as well :))

Or you could ask sundance if they have a board definition file for the
EDK so that you don't need to worry about it.

Good luck!

/Andreas

Article: 116571
Subject: faq
From: 4balaji@gmail.com
Date: 13 Mar 2007 00:02:38 -0700
Links: << >>  << T >>  << A >>
hi,this is balaji .I am doing my final year project using kcpsm3
(picoblaze).Any one sugg. any application using this core.Which i can
complete in around 20 days.
       thank u ,for responding


Article: 116572
Subject: Re: ddr sdram controller
From: birla.manish@gmail.com
Date: 13 Mar 2007 00:05:36 -0700
Links: << >>  << T >>  << A >>
On Mar 11, 1:44 am, dhruvaks...@gmail.com wrote:
> How can I get a ddr sdram  controller for the MT46V16M16TG -75 micron
> chip.
> I want a controller without  the plb or opb interface. I tried open
> cores.org but it says that the repository is empty with no files
> pertaining to the ddrsdram controller core.
> Could someone give me right pointers?
> Thanks,
> D.

You might want to have a look at Xilinx website itself. Its not very
high performance, but gives a good heads up.


Article: 116573
Subject: help !something wrong with Adaptive Filter (vhdl code)
From: kangwei365@gmail.com
Date: 13 Mar 2007 00:12:09 -0700
Links: << >>  << T >>  << A >>
3 parts partial products multiplier tap;LMP Adaptive Filter;Direct
form fir filter core
but quartus report that:
Error (10334): VHDL error at tap.vhd(82): entity "tsb" is used but not
declared
2 sections related to "tsb":

architecture Behavioral of tsb is
signal fo1, fo2 : std_logic;
signal data0 : std_logic_vector(3 downto 0);
signal data1 : std_logic_vector(3 downto 0);
signal data2 : std_logic_vector(3 downto 0);
signal data3 : std_logic_vector(3 downto 0);
begin
process(clk)
begin
if clk'event and clk = '1' then
data0 <= data_in;
data1 <= data0;
data2 <= data1;
data3 <= data2;
data_out <= data3;
-- Assert control bit for first octect
-- delay for 2 clk's
fo1 <= data3(3);
fo2 <= fo1;
first_oct <= fo2;
end if;
end process;
end Behavioral;



architecture Structural of tap is
component tsb is
Port ( clk : in std_logic;
data_in : in std_logic_vector(3 downto 0);
data_out : out std_logic_vector(3 downto 0);
first_oct : out std_logic );
end component


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
THE whole code :

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity tap is
Port ( clk : in std_logic;
rst : in std_logic;
Write_Data : in std_logic_vector(14 downto 0);
Bank_Sel : in std_logic;
Tap_Sel : in std_logic;
Write_Addr : in std_logic_vector(3 downto 0);
Read_Data : in std_logic_vector(3 downto 0);
Data_Valid : out std_logic;
Tap_out : out std_logic_vector(23 downto 0);
NT_tsb : out std_logic_vector(3 downto 0) );
end tap;
-----------------------------------------------------------------------
architecture Structural of tap is
component tsb is
Port ( clk : in std_logic;
data_in : in std_logic_vector(3 downto 0);
data_out : out std_logic_vector(3 downto 0);
first_oct : out std_logic );
end component;
component tap_lut is
Port ( clk : in std_logic;
write_en : in std_logic;
Write_Data : in std_logic_vector(14 downto 0);
lut_input : in std_logic_vector(3 downto 0);
lut_output : out std_logic_vector(14 downto 0) );
end component;
component mux_reg15 is

Port ( clk : in std_logic;
rst : in std_logic;
sel : in std_logic;
mux_in15a : in std_logic_vector(14 downto 0);
mux_in15b : in std_logic_vector(14 downto 0);
mux_out15 : out std_logic_vector(14 downto 0) );
end component;
component pp_adder is
Port ( clk : in std_logic;
rst : in std_logic;
f_oct : in std_logic;
valid : out std_logic;
input : in std_logic_vector(14 downto 0);
output : out std_logic_vector(23 downto 0) );
end component;
signal tsb_out : std_logic_vector(3 downto 0);
signal mux_1_out : std_logic_vector(3 downto 0);
signal mux_2_out : std_logic_vector(3 downto 0);
signal mux_3_out : std_logic_vector(14 downto 0);
signal First_oct : std_logic;
signal lut1_we : std_logic;
signal lut2_we : std_logic;
signal lut_1_out : std_logic_vector(14 downto 0);
signal lut_2_out : std_logic_vector(14 downto 0);
------------------------------------------------------------------------------
begin
TSB_1 : tsb port map(clk, Read_Data, tsb_out, First_oct);
--------------------- Partial Product Multiplier Section
----------------------
MUX_1 :
with Bank_Sel select
mux_1_out <= Write_Addr when '0',
tsb_out when others;
MUX_2 :
with Bank_Sel select
mux_2_out <= Write_Addr when '1',
tsb_out when others;
lut1_we <= not Bank_sel and Tap_Sel;
lut2_we <= Bank_sel and Tap_Sel;

LUT_1 : tap_lut port map(clk, lut1_we, Write_Data, mux_1_out,
lut_1_out);
LUT_2 : tap_lut port map(clk, lut2_we, Write_Data, mux_2_out,
lut_2_out);
------------------------- Scaling Accumulator Section
--------------------------
MUX_3 : mux_reg15 port map(clk, rst, Bank_Sel, lut_1_out, lut_2_out,
mux_3_out);
ADDER : pp_adder port
map(clk,rst,First_oct,Data_Valid,mux_3_out,Tap_out);
NT_tsb <= tsb_out;
end Structural;
-- tsb component
architecture Behavioral of tsb is
signal fo1, fo2 : std_logic;
signal data0 : std_logic_vector(3 downto 0);
signal data1 : std_logic_vector(3 downto 0);
signal data2 : std_logic_vector(3 downto 0);
signal data3 : std_logic_vector(3 downto 0);
begin
process(clk)
begin
if clk'event and clk = '1' then
data0 <= data_in;
data1 <= data0;
data2 <= data1;
data3 <= data2;
data_out <= data3;
-- Assert control bit for first octect
-- delay for 2 clk's
fo1 <= data3(3);
fo2 <= fo1;
first_oct <= fo2;
end if;
end process;
end Behavioral;
-- tap_lut Component
architecture Behavioral of tap_lut is
type lut_array is array (0 to 15) of std_logic_vector(14 downto 0);
signal lut_contents : lut_array;
begin
process(clk, write_en)
variable addr : integer range 0 to 15;

begin
if clk'event and clk = '1' then
addr := CONV_INTEGER(lut_input);
if write_en = '1' then
lut_contents(addr) <= Write_Data;
lut_output <= (others => '0');
else
lut_output <= lut_contents(addr);
end if;
end if;
end process;
end Behavioral;
-- mux_reg15 Component
architecture Behavioral of mux_reg15 is
signal mux_out15_sig : std_logic_vector(14 downto 0);
begin
with sel select
mux_out15_sig <= mux_in15a when '1',
mux_in15b when others;
REG: process(clk,rst)
begin
if rst = '1' then
mux_out15 <= (others => '0');
elsif clk'event and clk = '1' then
mux_out15 <= mux_out15_sig;
end if;
end process;
end Behavioral;
--pp_adder Component
architecture Behavioral of pp_adder is
signal f_o_delay : std_logic;
signal Adder_sig : std_logic_vector(17 downto 0);
signal LSB_0 : std_logic_vector(2 downto 0);
signal LSB_1 : std_logic_vector(2 downto 0);
signal LSB_2 : std_logic_vector(2 downto 0);
begin
process(clk, input, rst)
variable s_extend, a_extend : std_logic_vector(2 downto 0);
begin
if rst = '1' then
Adder_sig <= (others => '0');
LSB_0 <= (others => '0');
LSB_1 <= (others => '0');
LSB_2 <= (others => '0');

elsif clk'event and clk = '1' then
-- Sign extend for input and Adder_sig
for i in 2 downto 0 loop
s_extend(i) := input(14);
a_extend(i) := Adder_sig(17);
end loop;
f_o_delay <= f_oct;
if f_o_delay = '1' then
Adder_sig <= ( s_extend & input );
LSB_0 <= (others => '0');
LSB_1 <= (others => '0');
LSB_2 <= input(2 downto 0);
valid <= '1';
else
Adder_sig <= ( a_extend & Adder_sig(17 downto 3) ) + ( s_extend &
input );
LSB_0 <= LSB_1;
LSB_1 <= LSB_2;
LSB_2 <= Adder_sig(2 downto 0);
valid <= '0';
end if;
output <= Adder_sig(14 downto 0) & LSB_2 & LSB_1 & LSB_0;
end if;
end process;
end Behavioral;

-- Adaptive Filter Package
library IEEE;
use IEEE.STD_LOGIC_1164.all;
package ad_filt is
-- Declare constants
constant NUM_TAPS : integer := 16;
constant mu : integer := 16;
type sh_reg is array (0 to NUM_TAPS-1) of std_logic_vector(15 downto
0);
type tmp_reg is array (0 to NUM_TAPS-1) of std_logic_vector(31 downto
0);
end ad_filt;
-- LMS adaptive Filter
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;
library work;

use work.ad_filt.ALL;
entity lms_ad_filt is
Port ( clk : in std_logic;
rst : in std_logic;
train : in std_logic; -- 1 for yes, 0 for no
data_in : in std_logic_vector(15 downto 0);
new_data : in std_logic_vector(15 downto 0);
desired : in std_logic_vector(15 downto 0);
data_out : out std_logic_vector(15 downto 0) );
end lms_ad_filt;
architecture Behavioral of lms_ad_filt is
type states is (s0,s1,s2,s3,s4);
signal state : states;
signal coeffs : sh_reg;
signal inputs : sh_reg;
signal tmp : tmp_reg;
signal tmp1 : tmp_reg;
signal add_0 : std_logic_vector(31 downto 0);
signal add_1 : std_logic_vector(31 downto 0);
signal desired_0r : std_logic_vector(15 downto 0);
signal desired_1r : std_logic_vector(15 downto 0);
signal error : std_logic_vector(15 downto 0);
signal nd_0, nd_1 : std_logic_vector(15 downto 0);
begin
process(clk, rst, new_data)
variable output : std_logic_vector(31 downto 0);
begin
if rst = '1' then
state <= s0;
for i in 0 to NUM_TAPS-1 loop
inputs(i) <= (others=>'0');
tmp(i) <= (others=>'0');
coeffs(i) <= x"0001";
end loop;
data_out <= (others=>'0');
error <= (others=>'0');
desired_0r <= (others=>'0');
elsif rising_edge(clk) then
nd_0 <= new_data;
nd_1 <= nd_0;
case state is

when s0 =>
if (nd_0 /= nd_1) then -- new data available
state <= s1;
-- register desired output
desired_0r <= desired;
desired_1r <= desired_0r;
-- shift down input array
for i in NUM_TAPS-1 downto 1 loop
inputs(i) <= inputs(i-1);
end loop;
-- put new value in array
inputs(0) <= data_in;
-- compute direct form FIR
for i in 0 to NUM_TAPS-1 loop
tmp(i) <= inputs(i) * coeffs(i);
end loop;
else
-- wait for new data
state <= s0;
end if;
when s1 =>
state <= s2;
-- first adder stage
add_0 <= tmp(0)+tmp(1)+tmp(2)+tmp(3);
add_1 <= tmp(4)+tmp(5)+tmp(6)+tmp(7);
when s2 =>
-- second adder stage
output := add_0 + add_1;
data_out <= output(22 downto 7);
if train = '1' then
-- compute error
error <= desired_1r - output(22 downto 7); --divide by scale
state <= s3;
else
state <= s0;
end if;
when s3 =>
state <= s4;
-- update coefficients - first stage
for i in 0 to NUM_TAPS-1 loop
tmp1(i) <= inputs(i) * error;
end loop;
when s4 =>
state <= s0;
-- update coefficients

for i in 0 to NUM_TAPS-1 loop
coeffs(i) <= coeffs(i) + tmp1(i)(26 downto 11);--divide by scale & mu
end loop;
when others => state <= s0;
end case;
end if;
end process;
end Behavioral;

entity user_logic is
port (
Bus2IP_Addr : in std_logic_vector(0 to 31);
Bus2IP_Clk : in std_logic;
Bus2IP_CS : in std_logic;
Bus2IP_Data : in std_logic_vector(0 to 31);
Bus2IP_RdCE : in std_logic;
Bus2IP_Reset : in std_logic;
Bus2IP_WrCE : in std_logic;
IP2Bus_Data : out std_logic_vector(0 to 31) );
end entity user_logic;
-------------------------------------------------------------------------------
-- Architecture section
-------------------------------------------------------------------------------
architecture IMP of user_logic is
-------------------------------------------------------------------------------
-- Component Declaration
-------------------------------------------------------------------------------
component filter is
Port ( clk : in std_logic;
rst : in std_logic;
new_data : in std_logic_vector(15 downto 0);
valid : in std_logic_vector(15 downto 0);
coef_0 : in std_logic_vector(15 downto 0);
coef_1 : in std_logic_vector(15 downto 0);
coef_2 : in std_logic_vector(15 downto 0);
coef_3 : in std_logic_vector(15 downto 0);
coef_4 : in std_logic_vector(15 downto 0);
coef_5 : in std_logic_vector(15 downto 0);
coef_6 : in std_logic_vector(15 downto 0);
coef_7 : in std_logic_vector(15 downto 0);
coef_8 : in std_logic_vector(15 downto 0);
coef_9 : in std_logic_vector(15 downto 0);
coef_10 : in std_logic_vector(15 downto 0);
coef_11 : in std_logic_vector(15 downto 0);
coef_12 : in std_logic_vector(15 downto 0);

coef_13 : in std_logic_vector(15 downto 0);
coef_14 : in std_logic_vector(15 downto 0);
coef_15 : in std_logic_vector(15 downto 0);
result : out std_logic_vector(31 downto 0) );
end component;
-------------------------------------------------------------------------------
-- Signal declarations
-------------------------------------------------------------------------------
signal addr : std_logic_vector(0 to 4);
signal reg_0 : std_logic_vector(0 to 31);
signal reg_1 : std_logic_vector(0 to 31);
signal reg_2 : std_logic_vector(0 to 31);
signal reg_3 : std_logic_vector(0 to 31);
signal reg_4 : std_logic_vector(0 to 31);
signal reg_5 : std_logic_vector(0 to 31);
signal reg_6 : std_logic_vector(0 to 31);
signal reg_7 : std_logic_vector(0 to 31);
signal reg_8 : std_logic_vector(0 to 31);
signal reg_9 : std_logic_vector(0 to 31);
signal reg_10 : std_logic_vector(0 to 31);
signal reg_11 : std_logic_vector(0 to 31);
signal reg_12 : std_logic_vector(0 to 31);
signal reg_13 : std_logic_vector(0 to 31);
signal reg_14 : std_logic_vector(0 to 31);
signal reg_15 : std_logic_vector(0 to 31);
signal reg_16 : std_logic_vector(0 to 31);
signal reg_17 : std_logic_vector(0 to 31);
signal reg_18 : std_logic_vector(0 to 31);
signal reg_19 : std_logic_vector(0 to 31);
signal reg_20 : std_logic_vector(0 to 31);
signal reg_21 : std_logic_vector(0 to 31);
signal reg_22 : std_logic_vector(0 to 31);
signal reg_23 : std_logic_vector(0 to 31);
signal reg_24 : std_logic_vector(0 to 31);
signal reg_25 : std_logic_vector(0 to 31);
signal reg_26 : std_logic_vector(0 to 31);
signal reg_27 : std_logic_vector(0 to 31);
signal reg_28 : std_logic_vector(0 to 31);
signal reg_29 : std_logic_vector(0 to 31);
signal reg_30 : std_logic_vector(0 to 31);
signal reg_31 : std_logic_vector(0 to 31);
-------------------------------------------------------------------------------
-- Begin architecture
-------------------------------------------------------------------------------
begin -- architecture IMP

addr <= Bus2IP_Addr(25 to 29); -- bits 30 & 31 are dropped
REGS_PROC: process(Bus2IP_Clk) is
begin
if Bus2IP_Clk'event and Bus2IP_Clk='1' then
if Bus2IP_Reset = '1' then
reg_0 <= (others => '0');
reg_1 <= (others => '0');
reg_2 <= (others => '0');
reg_3 <= (others => '0');
reg_4 <= (others => '0');
reg_5 <= (others => '0');
reg_6 <= (others => '0');
reg_7 <= (others => '0');
reg_8 <= (others => '0');
reg_9 <= (others => '0');
reg_10 <= (others => '0');
reg_11 <= (others => '0');
reg_12 <= (others => '0');
reg_13 <= (others => '0');
reg_14 <= (others => '0');
reg_15 <= (others => '0');
reg_16 <= (others => '0');
reg_17 <= (others => '0');
-- reg_18 <= (others => '0'); result
reg_19 <= (others => '0');
reg_20 <= (others => '0');
reg_21 <= (others => '0');
reg_22 <= (others => '0');
reg_23 <= (others => '0');
reg_24 <= (others => '0');
reg_25 <= (others => '0');
reg_26 <= (others => '0');
reg_27 <= (others => '0');
reg_28 <= (others => '0');
reg_29 <= (others => '0');
reg_30 <= (others => '0');
reg_31 <= (others => '0');
else
if Bus2IP_CS = '1' and Bus2IP_WrCE = '1' then
case addr is
-- Address in EDK
when "00000" => reg_0 <= Bus2IP_Data; -- 00
when "00001" => reg_1 <= Bus2IP_Data; -- 04
when "00010" => reg_2 <= Bus2IP_Data; -- 08
when "00011" => reg_3 <= Bus2IP_Data; -- 0C
when "00100" => reg_4 <= Bus2IP_Data; -- 10

when "00101" => reg_5 <= Bus2IP_Data; -- 14
when "00110" => reg_6 <= Bus2IP_Data; -- 18
when "00111" => reg_7 <= Bus2IP_Data; -- 1C
when "01000" => reg_8 <= Bus2IP_Data; -- 20
when "01001" => reg_9 <= Bus2IP_Data; -- 24
when "01010" => reg_10 <= Bus2IP_Data; -- 28
when "01011" => reg_11 <= Bus2IP_Data; -- 2C
when "01100" => reg_12 <= Bus2IP_Data; -- 30
when "01101" => reg_13 <= Bus2IP_Data; -- 34
when "01110" => reg_14 <= Bus2IP_Data; -- 38
when "01111" => reg_15 <= Bus2IP_Data; -- 3C
when "10000" => reg_16 <= Bus2IP_Data; -- 40
when "10001" => reg_17 <= Bus2IP_Data; -- 44
-- when "10010" => reg_18 <= Bus2IP_Data; -- 48
when "10011" => reg_19 <= Bus2IP_Data; -- 4C
when "10100" => reg_20 <= Bus2IP_Data; -- 50
when "10101" => reg_21 <= Bus2IP_Data; -- 54
when "10110" => reg_22 <= Bus2IP_Data; -- 58
when "10111" => reg_23 <= Bus2IP_Data; -- 5C
when "11000" => reg_24 <= Bus2IP_Data; -- 60
when "11001" => reg_25 <= Bus2IP_Data; -- 64
when "11010" => reg_26 <= Bus2IP_Data; -- 68
when "11011" => reg_27 <= Bus2IP_Data; -- 6C
when "11100" => reg_28 <= Bus2IP_Data; -- 70
when "11101" => reg_29 <= Bus2IP_Data; -- 74
when "11110" => reg_30 <= Bus2IP_Data; -- 78
when "11111" => reg_31 <= Bus2IP_Data; -- 7C
when others => null;
end case;
end if;
end if;
end if;
end process REGS_PROC;
OUT_MUX: process(addr) is
begin
case addr is
when "00000" => IP2Bus_Data <= reg_0;
when "00001" => IP2Bus_Data <= reg_1;
when "00010" => IP2Bus_Data <= reg_2;
when "00011" => IP2Bus_Data <= reg_3;
when "00100" => IP2Bus_Data <= reg_4;
when "00101" => IP2Bus_Data <= reg_5;
when "00110" => IP2Bus_Data <= reg_6;
when "00111" => IP2Bus_Data <= reg_7;
when "01000" => IP2Bus_Data <= reg_8;

when "01001" => IP2Bus_Data <= reg_9;
when "01010" => IP2Bus_Data <= reg_10;
when "01011" => IP2Bus_Data <= reg_11;
when "01100" => IP2Bus_Data <= reg_12;
when "01101" => IP2Bus_Data <= reg_13;
when "01110" => IP2Bus_Data <= reg_14;
when "01111" => IP2Bus_Data <= reg_15;
when "10000" => IP2Bus_Data <= reg_16;
when "10001" => IP2Bus_Data <= reg_17;
when "10010" => IP2Bus_Data <= reg_18;
when "10011" => IP2Bus_Data <= reg_19;
when "10100" => IP2Bus_Data <= reg_20;
when "10101" => IP2Bus_Data <= reg_21;
when "10110" => IP2Bus_Data <= reg_22;
when "10111" => IP2Bus_Data <= reg_23;
when "11000" => IP2Bus_Data <= reg_24;
when "11001" => IP2Bus_Data <= reg_25;
when "11010" => IP2Bus_Data <= reg_26;
when "11011" => IP2Bus_Data <= reg_27;
when "11100" => IP2Bus_Data <= reg_28;
when "11101" => IP2Bus_Data <= reg_29;
when "11110" => IP2Bus_Data <= reg_30;
when "11111" => IP2Bus_Data <= reg_31;
when others => IP2Bus_Data <= (others => '0');
end case;
end process OUT_MUX;
-------------------------------------------------------------------------------
-- Component Instantiation
-------------------------------------------------------------------------------
FILTER_0 : filter
port map(
clk => Bus2IP_Clk,
rst => Bus2IP_Reset,
new_data => reg_16(16 to 31),
valid => reg_17(16 to 31),
coef_0 => reg_0(16 to 31),
coef_1 => reg_1(16 to 31),
coef_2 => reg_2(16 to 31),
coef_3 => reg_3(16 to 31),
coef_4 => reg_4(16 to 31),
coef_5 => reg_5(16 to 31),
coef_6 => reg_6(16 to 31),
coef_7 => reg_7(16 to 31),
coef_8 => reg_8(16 to 31),
coef_9 => reg_9(16 to 31),
coef_10 => reg_10(16 to 31),

coef_11 => reg_11(16 to 31),
coef_12 => reg_12(16 to 31),
coef_13 => reg_13(16 to 31),
coef_14 => reg_14(16 to 31),
coef_15 => reg_15(16 to 31),
result => reg_18 );
end architecture IMP;
entity filter is
Port ( clk : in std_logic;
rst : in std_logic;
new_data : in std_logic_vector(15 downto 0);
valid : in std_logic_vector(15 downto 0);
coef_0 : in std_logic_vector(15 downto 0);
coef_1 : in std_logic_vector(15 downto 0);
coef_2 : in std_logic_vector(15 downto 0);
coef_3 : in std_logic_vector(15 downto 0);
coef_4 : in std_logic_vector(15 downto 0);
coef_5 : in std_logic_vector(15 downto 0);
coef_6 : in std_logic_vector(15 downto 0);
coef_7 : in std_logic_vector(15 downto 0);
coef_8 : in std_logic_vector(15 downto 0);
coef_9 : in std_logic_vector(15 downto 0);
coef_10 : in std_logic_vector(15 downto 0);
coef_11 : in std_logic_vector(15 downto 0);
coef_12 : in std_logic_vector(15 downto 0);
coef_13 : in std_logic_vector(15 downto 0);
coef_14 : in std_logic_vector(15 downto 0);
coef_15 : in std_logic_vector(15 downto 0);
result : out std_logic_vector(31 downto 0) );
end filter;
architecture Behavioral of filter is
constant NUM_TAPS : integer := 15; -- one less
constant scale : integer := 256;
type data_reg0 is array (0 to NUM_TAPS) of std_logic_vector(15 downto
0);
type data_reg1 is array (0 to NUM_TAPS) of std_logic_vector(31 downto
0);
signal coeffs : data_reg0; -- array for holding coefficients
signal inputs : data_reg0; -- shift register for inputs
signal tmp : data_reg1;
signal val_0 : std_logic_vector(15 downto 0);
signal val_1 : std_logic_vector(15 downto 0);
signal add_0, add_1 : std_logic_vector(31 downto 0);
begin
process(clk, rst, new_data, valid) is
variable tmp0 : std_logic_vector(31 downto 0);

begin
if (rst = '1') then
for i in 0 to NUM_TAPS loop
tmp(i) <= (others => '0');
inputs(i) <= (others => '0');
end loop;
add_0 <= (others => '0');
add_1 <= (others => '0');
elsif clk'event and clk = '1' then
val_0 <= valid; -- shift down to
val_1 <= val_0; -- catch event
if (val_0 /= val_1) then -- new data
-- shift in new input
for i in NUM_TAPS downto 1 loop
inputs(i) <= inputs(i-1);
end loop;
inputs(0) <= new_data;
-- multiply inputs and coefficients
for i in 0 to NUM_TAPS loop
--tmp(i) <= inputs(i) * coeffs(i);
tmp0 := inputs(i) * coeffs(i);
tmp(i) <= tmp0(31)&tmp0(31)&tmp0(31)&tmp0(31)&tmp0(31)
&tmp0(31)&tmp0(31)&tmp0(31)&tmp0(31 downto 8);
end loop;
-- pipeline 1 stage
add_0 <= tmp(0)+tmp(1)+tmp(2)+tmp(3)+tmp(4)
+tmp(5)+tmp(6)+tmp(7);
add_1 <= tmp(8)+tmp(9)+tmp(10)+tmp(11)+tmp(12)
+tmp(13)+tmp(14)+tmp(15);
result <= add_0 + add_1;
end if;
end if;
end process;
-- put coefficients into array
coeffs(0) <= coef_0;
coeffs(1) <= coef_1;
coeffs(2) <= coef_2;
coeffs(3) <= coef_3;
coeffs(4) <= coef_4;
coeffs(5) <= coef_5;
coeffs(6) <= coef_6;
coeffs(7) <= coef_7;
coeffs(8) <= coef_8;
coeffs(9) <= coef_9;
coeffs(10) <= coef_10;

coeffs(11) <= coef_11;
coeffs(12) <= coef_12;
coeffs(13) <= coef_13;
coeffs(14) <= coef_14;
coeffs(15) <= coef_15;
end Behavioral;


Article: 116574
Subject: Re: Dual edge detection
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 13 Mar 2007 01:25:39 -0700
Links: << >>  << T >>  << A >>
Hi John,

yes that what the approach I was thinking of: changing to one clock
domain.
The point is to constraint the timing when changing from one clock
domain
to the other.
Thank you for your opinion.

Mike, usenet is sometimes also poor in answering with more than
a couple of single words.

Rgds
Andre





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