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 108950

Article: 108950
Subject: Fixed-point FIR eyediagram problem
From: "YFLuo" <yifei.luo@unh.edu>
Date: Tue, 19 Sep 2006 12:13:46 -0400
Links: << >>  << T >>  << A >>
Hi,

I am designing a fixed-point FIR using Xilinx block set.But it seems that 
only the upper half of the output eyediagram ramains while the lower half 
has been truncated.In the design, I just use random integer Generator, then 
going through a Gateway In block, then upsampling block, then fixed-point 
FIR filer,Gateway Out block, AWGN block, Gateway In block, fixed-point FIR 
filter, downsampling, Gateway Out block and output display.
Could anyone give me some suggestions about this eyediagram problem?

Thanks a lot! 



Article: 108951
Subject: Re: resets on synplicity inferred RAMs
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 19 Sep 2006 16:14:31 GMT
Links: << >>  << T >>  << A >>
It's *possible* to create rams with resets in ASICs and FPGAs, just not at 
all recommended.  In the ASICs, you will no longer be able to leverage the 
precompiled memory libraries available from the vendor.  I know of no 
vendors that have memories with resets as part of their standard offering. 
In the Synplify tool, you can include a reset in your inference and the 
synthesizer will dutifully implement your memory in registers.

Another consideration: for large memories, consider the current surge 
required to change all those bits at once.  While a 20k LUT device is 
expected to be completely reset with one pulse, would 20 18 kBit memories 
fare so well?  There are too many reasons not to include a RAM reset and too 
many workarounds to include it.

You have the choice of running through the initialization in a separate 
routine or keeping track of what data has been modified with "dirty bits" as 
another poster suggested.

This idea is not new to electronics.  There are plenty of people who have 
considered and rejected the idea for reasons of cost, power, practicality.


"vssumesh" <vssumesh_asic@yahoo.com> wrote in message 
news:1158676176.258708.22080@i42g2000cwa.googlegroups.com...
> One more doubt Ray, I am an FPGA based designer also a beginer. My
> doubt is if due to some reasons i want a reset signal for a RAM block
> for which i am ready to sacrifice the area and fanout problem is it
> possible to create one in ASIC.
> Sumesh
>
> Ray Andraka wrote:
>> vssumesh wrote:
>>
>> > Why there is such a limitation. Why cant we pass a rest to all ram
>> > cells. Please advice me.
>> > Thanks and regards
>> > Sumesh V S
>> >
>>
>> The reason is the silicon does not support it, there is no reset line
>> that clears the RAM.  The reason it is not designed into the silicon is
>> that adding a reset just about doubles the size of a RAM cell, plus
>> requires a very high fan-out signal.  The area and speed implications
>> are both strong disincentives to including a reset that clears the whole
>> array at once.
> 



Article: 108952
Subject: Re: Fixed-point FIR eyediagram problem
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 19 Sep 2006 09:16:27 -0700
Links: << >>  << T >>  << A >>
YFLuo wrote:

> Hi,
> 
> I am designing a fixed-point FIR using Xilinx block set.But it seems that 
> only the upper half of the output eyediagram ramains while the lower half 
> has been truncated.In the design, I just use random integer Generator, then 
> going through a Gateway In block, then upsampling block, then fixed-point 
> FIR filer,Gateway Out block, AWGN block, Gateway In block, fixed-point FIR 
> filter, downsampling, Gateway Out block and output display.
> Could anyone give me some suggestions about this eyediagram problem?
> 
> Thanks a lot! 
> 
> 
Is this in Matlab?  Check the blockset for how it treats negative 
numbers -- it may be displaying exactly the correct behavior.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 108953
Subject: Re: VHDL oddity
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 19 Sep 2006 09:25:21 -0700
Links: << >>  << T >>  << A >>

> Yes, I hadn't yet modeled it.  It works fine in the simulator for me as
> well.  The problem appears when I run it on our hardware.  So now I'm
> left even more stumped.

You are scoping it? Or it's a video display?

It could be a rise time issue if the clock is too fast.
That would explain how you see the "0001010" when you
leave the else statement out.

Brad Smallridge
aivision


>> >                if column_out(0)='0' then
>> >                    bDATA_OUT <= "00001010";
>> >                else
>> >                    bDATA_OUT <= "11000000";
>> >                end if;



Article: 108954
Subject: Re: ddr clock issues
From: Tommy Thorn <foobar@nowhere.void>
Date: Tue, 19 Sep 2006 09:25:44 -0700
Links: << >>  << T >>  << A >>
David Ashley wrote:
> One thing of note -- this is on the spartan-3e starter board.
> It supplies a 50 mhz clock. I run this through a DCM to produce
> 100 mhz, and that's use to feed the other 2 DCM's. I kind of
> remember this is not a good idea?

The whole issue of DDR clock management and pin constraints is an area 
I'm not too comfortable with. I wish X and A would include with their 
development boards _simple_ example frobbing their SDRAM. Just enough to 
show that it's working, not a complete controller. I can design the 
logic for controller for SDRAM (DDR or SDR) just fine, but it seems 
every FPGA (and board) have different clocking methodology and 
constraints requirements.

David, I hope you find the solution and share it with us :-)

I assume there won't be too much difference between the ML401 (Virtex 4) 
and the Spartan 3E starter kit.

Tommy

Article: 108955
Subject: Re: FPGA : Open core FFT
From: "tullio" <tullio.grassi@gmail.com>
Date: 19 Sep 2006 09:27:36 -0700
Links: << >>  << T >>  << A >>
we use this fft from opencores:

-- Title       : cfft64X12
-- Design      : cfft
-- Author      : ZHAO Ming

it seems ok to us other than it generates a lot of waring in simulation
due to uninitialized signels.
Plus XST8.2.2 synthesis is wrong where the keyword "signed" is used.
Other synthesisers like Synplify Pro do it ok.


bijoy ha scritto:

> Hi all,
>
> Does any one used Open core FFT.
>
> I am trying to use it, but what my simulation results shows is that the performance of the FFT does not match with the other FFT cores available from other vendors(eg. xilinx).
>
> The magnitude of the result seems matching except the attenuation of the side lobs is not so good.
>
> But what i am afraid is that the phase response of the FFT result is very bad compared to FFT result from matlab or from other vendors.
>
> Can anybody help me if you have used open core FFT .
> 
> Thanks in advance
> 
> rgds bijoy


Article: 108956
Subject: Re: Using a global clock as a flip-flop enable?
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 19 Sep 2006 16:30:57 GMT
Links: << >>  << T >>  << A >>
"mav1101" <maverick1101@hotmail.com> wrote:

>Hi all,
>
>I've heard that a good rule of thumb is to not to use a global clock as
>an enable for flops or RAMs. Even though static timing numbers might
>look ok, are there any consequences of doing this?

It is better to create a signal which is a copy of the clock sampled
by a clock which twice the original clock frequency.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108957
Subject: Re: Fixed-point FIR eyediagram problem
From: "YFLuo" <yifei.luo@unh.edu>
Date: Tue, 19 Sep 2006 12:41:06 -0400
Links: << >>  << T >>  << A >>
Thanks, Tim.

Yes, I do it in MatLab. I have designed a floating-point FIR and the 
eyediagram is good. Should I add some blocks which function as channel 
encoding/decoding or something else to my fixed-point FIR design? I am not 
sure about that.

YFLuo

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:acydnQQScfBEio3YnZ2dnUVZ_uudnZ2d@web-ster.com...
> YFLuo wrote:
>
>> Hi,
>>
>> I am designing a fixed-point FIR using Xilinx block set.But it seems that 
>> only the upper half of the output eyediagram ramains while the lower half 
>> has been truncated.In the design, I just use random integer Generator, 
>> then going through a Gateway In block, then upsampling block, then 
>> fixed-point FIR filer,Gateway Out block, AWGN block, Gateway In block, 
>> fixed-point FIR filter, downsampling, Gateway Out block and output 
>> display.
>> Could anyone give me some suggestions about this eyediagram problem?
>>
>> Thanks a lot!
> Is this in Matlab?  Check the blockset for how it treats negative 
> numbers -- it may be displaying exactly the correct behavior.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> Posting from Google?  See http://cfaj.freeshell.org/google/
>
> "Applied Control Theory for Embedded Systems" came out in April.
> See details at http://www.wescottdesign.com/actfes/actfes.html 



Article: 108958
Subject: Re: Spartan3: Multiplier Madness
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 19 Sep 2006 16:42:34 GMT
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote:

>Nico,
>
>OK, here it is: (for S3, V2, and V2 Pro)
>
>"It is likely that the delay will be marginally smaller if you
>tie the 2 LSB inputs and use the upper 16 inputs only.  However, the
>software model is pretty simple and won't model that as far as I can
>remember.  Also, since one of the inputs goes through the Booth encoder
>it might not be as substantial of an improvement as it would be with an
>"original recipe" multiplier."

So what you are saying is that the multiplier is faster when the upper
inputs are being used, but the place & route software assumes the
upper bits are slower?

>So, there you go.  Looks like sign extension is the only 'official' way
>to go, but there will be some fat (overestimation of delay) in the set
>the lsb's to 0 solution, and the software will not model it, and yet it
>may be a small improvement over what is predicted.
>
>Sorry if this is just too slow,

I can move to a speed grade 5 device and I'll be fine.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108959
Subject: Avnet LX25 Evaluation Board - USB Problems
From: "al99999" <alastairlynch@gmail.com>
Date: 19 Sep 2006 09:46:35 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm really struggling to get the Avnet LX25 Evaluation Boards USB port
working.  I have downloaded their USB Utility and instructions from the
avnet design resource centre but they are not very helpful.

When I connect to the board using avnets usb utility a dialog appears
asking me to confirm the board I have connected.  It is meant to say V4
Dev but the only option is unknown device.  I have altered the jumper
settings as per the instructions.  On board is a Cypress 68013, do I
need to program this with something first using the Cypress dev tools,
or is it preloaded.  Perhaps there is a hex file to configure the
cypress chip in the usb utility somewhere but I cant find it.

Any help would be greatly appreciated.

Thanks in advance.

Al


Article: 108960
Subject: Re: ddr clock issues
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 19 Sep 2006 09:57:39 -0700
Links: << >>  << T >>  << A >>
Tommy Thorn wrote:
> David Ashley wrote:
> 
>> One thing of note -- this is on the spartan-3e starter board.
>> It supplies a 50 mhz clock. I run this through a DCM to produce
>> 100 mhz, and that's use to feed the other 2 DCM's. I kind of
>> remember this is not a good idea?
> 
> 
> The whole issue of DDR clock management and pin constraints is an area
> I'm not too comfortable with. I wish X and A would include with their
> development boards _simple_ example frobbing their SDRAM. Just enough to
> show that it's working, not a complete controller. I can design the
> logic for controller for SDRAM (DDR or SDR) just fine, but it seems
> every FPGA (and board) have different clocking methodology and
> constraints requirements.
> 
> David, I hope you find the solution and share it with us :-)
> 
> I assume there won't be too much difference between the ML401 (Virtex 4)
> and the Spartan 3E starter kit.
> 
> Tommy

I will certainly share whatever I learn.

One thing just occured to me. BTW I don't have any test equipment,
no 'scope, no logic analyzer, nothing. Just a crappy digital multimeter.
So I can't hook a scope up and look at the signals going into the DDR
itself.

For some reason I think the data going into the DDR is good. The
open cores controller does include logic to generate the DQS strobe
the DDR uses to latch input data. That approach would tend to
balance out timing problems -- the same logic that drives the data
also drives the DQS strobe, so they should sink or swim together
I suppose.

But the open cores DDR doesn't make use of the DQS strobe generated
by the DDR device itself. I'm only trying to run at 100 mhz. In that
case xilinx app notes say the timing is adequate so the DQS strobe isn't
needed to capture data reliably. Maybe the timing would get easier if
the logic made use of the DQS strobe from the DDR.

I have a feeling adding some constraints would make the thing work
with a single DCM. Unfortunately I have no clue what constraints to
add, as I don't know what's going wrong (and don't know much about
constraints writing anyway).

To get around the lack of test equipment, when the thing wasn't
working before I created a module called "vgatext" which outputs
a 96x40 stable text display to the vga outputs. Then I set up so in
the event of a ddr error it will display the desired data vs the actual
data -- and saw it was an off-by-one problem. That was a problem in
my logic but not in the timing.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108961
Subject: Re: Buffering the critical path.
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 19 Sep 2006 10:07:51 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> What kind of device are you using?
> 20 ns for a 32-bit adder (using dedicated carry) would be ridiculously
> slow...
> Dedicated carry, available in all Xilinx FPGA devices, uses less than
> 50 ps per bit (plus some basic delay).
> Peter Alfke
>
> ===========
> vssumesh wrote:
> > Hello all,
> >    In my design i am using a 32 bit adder and some combinational logic
> > after that. The full path i want to constrain to double the clock
> > period (20ns) and it is not constraing. When analysed the critical path
> > observed that there is big carry chain for the adder and a big routing
> > delay between the combinational logic (which i never expected). Is the
> > big carry chain is causing the trouble in the router. I am thinking of
> > buffering the output of the adder with a -ve edge (constrain that path
> > to 5ns). And then constrain the other path that is after the buffer to
> > next stage FF to 16ns. Will this buffering ease the routing effort.
> > Please advice.
> > Thanks and regards
> > Sumesh V S
No 20ns for the adder and the remaining combinational logic. The adder
delay is as you said is very much less.


Article: 108962
Subject: Re: Performance Appraisals
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 19 Sep 2006 10:14:03 -0700
Links: << >>  << T >>  << A >>

> successful. For those companies where this is not true, I'd change
> jobs, unless you have decided this a comfortable retirement job, AND
> you have some faith they will let you stay to retirement. Even then,
> I'd change jobs, because I HATE the lack of challenge in my job.

Last line is really really good......


Article: 108963
Subject: Hilbert Transform in verilog or VHDL -- it has got to be out there
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 19 Sep 2006 10:21:17 -0700
Links: << >>  << T >>  << A >>
OK,

I have looked through a lot of places, but it seems that opencores.org,
etc. just do not have any Hilbert transform blocks.

I would think that this is not exactly rocket science, as the common
ways to do this are posted all over the place, and there are c programs
for DSP also posted.  Even the Xilinx DSP libraries don't seem to have a
free Hibert transformer (even one for $?).

Yes, I know how to go about doing one, but, if its already done, why
recode the wheel?  After all, there are probably at least three good
ways to do it on an FPGA, and ten bad ones.

Since I have "friends in low places" in ham radio, having a public
domain Hilbert would be useful for SSB, FM, AMSAT and other SDR
applications.

Some FIR, IIR, FFT, mixers, accumulators, DDFS, and so forth that are
pretty easily found plus a Digilent $99 S200 pcb could make a useful
foundation for software defined radio experiments (that and a
http://www.digilentinc.com/Products/Detail.cfm?Prod=AIO1&Nav1=Products&Nav2=Accessory
analog accessory pcb, or make your own A/D, D/A pcb).

If anyone can point me to some sources, it would be appreciated.

By the way, the TAPR class went well on Sunday in Tuscon, and now there
are 28 more crazy hams out there who are really dangerous...

The talk and slides will be posted when they do their web page for the
2006 25th anniversary meeting.

http://www.tapr.org

Austin

Article: 108964
Subject: Re: Buffering the critical path.
From: "Peter Alfke" <peter@xilinx.com>
Date: 19 Sep 2006 10:38:29 -0700
Links: << >>  << T >>  << A >>
Vessumesh, if you refuse to answer specific helpful questions, then I
suggest you figure this out yourself, and do not bother this newsgroup.
Peter

vssumesh wrote:
> Peter Alfke wrote:
> > What kind of device are you using?
> > 20 ns for a 32-bit adder (using dedicated carry) would be ridiculously
> > slow...
> > Dedicated carry, available in all Xilinx FPGA devices, uses less than
> > 50 ps per bit (plus some basic delay).
> > Peter Alfke
> >
> > ===========
> > vssumesh wrote:
> > > Hello all,
> > >    In my design i am using a 32 bit adder and some combinational logic
> > > after that. The full path i want to constrain to double the clock
> > > period (20ns) and it is not constraing. When analysed the critical path
> > > observed that there is big carry chain for the adder and a big routing
> > > delay between the combinational logic (which i never expected). Is the
> > > big carry chain is causing the trouble in the router. I am thinking of
> > > buffering the output of the adder with a -ve edge (constrain that path
> > > to 5ns). And then constrain the other path that is after the buffer to
> > > next stage FF to 16ns. Will this buffering ease the routing effort.
> > > Please advice.
> > > Thanks and regards
> > > Sumesh V S
> No 20ns for the adder and the remaining combinational logic. The adder
> delay is as you said is very much less.


Article: 108965
Subject: Re: VHDL oddity
From: "Rajeev" <rrr@ieee.org>
Date: 19 Sep 2006 10:47:52 -0700
Links: << >>  << T >>  << A >>
Alex,

Couple of things strike me as cause for concern, being rusty on my VHDL
I don't recall the semantics of incomplete specifications, ans would
hesitate to say any of these comments will help, but still...

1. if mode='0' clause does not define signals bDATA_OUT and
column_out[].
2. not sure why you have elsif mode='1' instead of just "else" --
synthesis is one thing but simulation considers 'X' 'U' 'Z' etc
(9-value logic) and it's prudent to have "else" specified.
3. synthesis and simulation may not implement logic identically.

HTH,

-rajeev-

Alex wrote:
> I would greatly appreciate if someone could explain the behavior I'm
> seeing for me.
>
> In the inner most if-state, where I write to bDATA_OUT ---- if I run
> the program as written, it does nothing (my DATA_OUT lines remain in
> the state they were previously).  If I remove the "else,   bDATA_OUT <=
> "11000000"" segment, it properly outputs 00001010.  I don't understand
> why it would work w/o the else, but not w/.
>
> This is a snippet of a larger VHDL, trimmed down for debugging.
>
> Thank you.
>
> Alex McHale
>
> entity driver is
>     Port ( CLOCK : in  STD_LOGIC;
>            ACTIVE : in STD_LOGIC;
>            CLOCK_IN : in  STD_LOGIC;
>            LATCH_IN : in  STD_LOGIC;
>            DATA_IN : in  STD_LOGIC_VECTOR (7 downto 0);
>            ADDRESS_IN : in  STD_LOGIC_VECTOR (4 downto 0);
>            DATA_CLOCK_OUT : out STD_LOGIC;
>            CLOCK_OUT : out  STD_LOGIC;
>            LATCH_OUT : out  STD_LOGIC;
>            DATA_OUT : out  STD_LOGIC_VECTOR (7 downto 0) );
> end driver;
>
> architecture Behavioral of driver is
>     signal mode : STD_LOGIC := '0';
>     signal column_out : STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
>     signal bDATA_OUT : STD_LOGIC_VECTOR(7 downto 0);
> begin
>     process( CLOCK )
>     begin
>         if( rising_edge( CLOCK ) ) then
>             if mode='0' then
>                 CLOCK_OUT <= '0';
>                 LATCH_OUT <= '0';
>
>                 mode <= '1';
>             elsif mode='1' then -- DATA INCOMING
>                 if column_out(0)='0' then
>                     bDATA_OUT <= "00001010";
>                 else
>                     bDATA_OUT <= "11000000";
>                 end if;
>
>                 CLOCK_OUT <= '1';
>                 LATCH_OUT <= '1';
>                 column_out <= column_out + 1;
>
>                 mode <= '0';
>             end if;
>         end if;
>     end process;
> 
>     DATA_OUT <= bDATA_OUT;
> end Behavioral;


Article: 108966
Subject: Re: VHDL oddity
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 19 Sep 2006 10:51:01 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
>>Yes, I hadn't yet modeled it.  It works fine in the simulator for me as
>>well.  The problem appears when I run it on our hardware.  So now I'm
>>left even more stumped.
> 
> 
> You are scoping it? Or it's a video display?
> 
> It could be a rise time issue if the clock is too fast.
> That would explain how you see the "0001010" when you
> leave the else statement out.
> 
> Brad Smallridge
> aivision
> 
> 
> 
>>>>               if column_out(0)='0' then
>>>>                   bDATA_OUT <= "00001010";
>>>>               else
>>>>                   bDATA_OUT <= "11000000";
>>>>               end if;
> 
> 
> 

What clock rate is this running at? Is it meeting timing?
Having the "if" might slow the circuit down.

Of course now that I think about it maybe not:
  tbit <= column_out(0);
bDATA_OUT <= tbit & tbit & '0' & '0' & not tbit &
       '0' & not tbit & '0';
Can be used to replace the if, but the synthesizer
is probably doing this already.

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108967
Subject: Re: xilinx or altera?
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 19 Sep 2006 10:53:07 -0700
Links: << >>  << T >>  << A >>
One last comment.... ifound the support from xilinx as very very good
really excellent!!!!
 Dont know about altera but i dont think they can match that!
But the related to supply of HW or related stuffs got a very poor
response!
regards
Sumesh


Article: 108968
Subject: Re: VHDL oddity
From: "Marlboro" <ccon67@netscape.net>
Date: 19 Sep 2006 10:55:43 -0700
Links: << >>  << T >>  << A >>
Alex,
Its better to see your RTL shematic, anyway try this if it makes
difference.  Doubt if it is what you need :)

signal test std_logic;
...
    test <=  column_out(0);

    process( CLOCK )
    begin
        if( rising_edge( CLOCK ) ) then

            mode <= not(mode);
            CLOCK_OUT <= mode;
            LATCH_OUT <= mode;

            if mode='1' then -- DATA INCOMING
                bDATA_OUT <= 'test' &'test'&"00"& not(test) & '0' &
not(test) & '0';
                column_out <= column_out + 1;
            end if;

        end if;
    end process;
...

Alex wrote:
> Yes, I hadn't yet modeled it.  It works fine in the simulator for me as
> well.  The problem appears when I run it on our hardware.  So now I'm
> left even more stumped.
>
>
> Brad Smallridge wrote:
> > Hi Alex,
> >
> > I modeled this with ISE 7.1 and ModelSimXE III 6.0d and the
> > DATA_OUT alternates between 00001010 and 11000000 as I expected.
> >
> > I am not sure what you expected to see.
> >
> > Brad Smallridge
> > aivision
> >
> >
> >
> > "Alex" <alexmchale@gmail.com> wrote in message
> > news:1158680022.780556.64880@e3g2000cwe.googlegroups.com...
> > >I would greatly appreciate if someone could explain the behavior I'm
> > > seeing for me.
> > >
> > > In the inner most if-state, where I write to bDATA_OUT ---- if I run
> > > the program as written, it does nothing (my DATA_OUT lines remain in
> > > the state they were previously).  If I remove the "else,   bDATA_OUT <=
> > > "11000000"" segment, it properly outputs 00001010.  I don't understand
> > > why it would work w/o the else, but not w/.
> > >
> > > This is a snippet of a larger VHDL, trimmed down for debugging.
> > >
> > > Thank you.
> > >
> > > Alex McHale
> > >
> > > entity driver is
> > >    Port ( CLOCK : in  STD_LOGIC;
> > >           ACTIVE : in STD_LOGIC;
> > >           CLOCK_IN : in  STD_LOGIC;
> > >           LATCH_IN : in  STD_LOGIC;
> > >           DATA_IN : in  STD_LOGIC_VECTOR (7 downto 0);
> > >           ADDRESS_IN : in  STD_LOGIC_VECTOR (4 downto 0);
> > >           DATA_CLOCK_OUT : out STD_LOGIC;
> > >           CLOCK_OUT : out  STD_LOGIC;
> > >           LATCH_OUT : out  STD_LOGIC;
> > >           DATA_OUT : out  STD_LOGIC_VECTOR (7 downto 0) );
> > > end driver;
> > >
> > > architecture Behavioral of driver is
> > >    signal mode : STD_LOGIC := '0';
> > >    signal column_out : STD_LOGIC_VECTOR(9 downto 0) := "0000000000";
> > >    signal bDATA_OUT : STD_LOGIC_VECTOR(7 downto 0);
> > > begin
> > >    process( CLOCK )
> > >    begin
> > >        if( rising_edge( CLOCK ) ) then
> > >            if mode='0' then
> > >                CLOCK_OUT <= '0';
> > >                LATCH_OUT <= '0';
> > >
> > >                mode <= '1';
> > >            elsif mode='1' then -- DATA INCOMING
> > >                if column_out(0)='0' then
> > >                    bDATA_OUT <= "00001010";
> > >                else
> > >                    bDATA_OUT <= "11000000";
> > >                end if;
> > >
> > >                CLOCK_OUT <= '1';
> > >                LATCH_OUT <= '1';
> > >                column_out <= column_out + 1;
> > >
> > >                mode <= '0';
> > >            end if;
> > >        end if;
> > >    end process;
> > >
> > >    DATA_OUT <= bDATA_OUT;
> > > end Behavioral;
> > >


Article: 108969
Subject: Re: Buffering the critical path.
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 19 Sep 2006 10:58:03 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Vessumesh, if you refuse to answer specific helpful questions, then I
> suggest you figure this out yourself, and do not bother this newsgroup.
> Peter

Peter,

He probably got thrown off by the top-posting format of your
question. Forgive him. :)

http://www.catb.org/jargon/html/T/top-post.html

> A: No.
> Q: Should I include quotations after my reply?

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108970
Subject: Re: upgrading firmware on stratix 2 without NIOS IDE
From: "Jeff Johnson" <jeffjohnsonce@gmail.com>
Date: 19 Sep 2006 11:01:08 -0700
Links: << >>  << T >>  << A >>
JEFF WRITES

I am sorry for asking a vague question....I will be more specific now.
On the NIOS 2 processor I am using on the Stratix 2 FPGA, i already
have the ability to write to flash once the data is on the board, and I
can transfer data to the board.  My real problem is knowing what to
send to the board.  I am Using the NIOS 2 IDE to compile the firmware
for this board.  What i would like to do is be able to send (over
RS232......i know...i know) but over this existing link i'd like to be
able to send the new executable.  the problem is i don't know anything
about what file or format to send to the FPGA.  I have read some other
postings of people that have attempted to use the NIOS 2 IDE output
files, and everyone seems to be of the mind that the file are in the
wrong format, and need to be converted.

again sorry for being vague

Jeffrey Johnson

Ben Twijnstra wrote:
> Jeff Johnson wrote:
>
> > so the question is........i think.......how do you reformat the output
> > of the NIOS IDE output files so they can be saved to flash and
> > successfuilly rebooted.
>
> In principle, this completely depends on the type of flash you use. If you
> look into the datasheet of the flash chips you're using, there should be a
> detailed section on how to erase a page of flash, how to bulk-erase the
> whole chip etc, and, most importantly, how to program an empty page of
> flash.
>
> Basically, there's two types of flash, namely Intel and AMD type flash. Both
> types use different programming algorithms. Newer flash devices offer
> something called CFI (Common Flash Interface), where you send a bunch of
> very specific write commands to the flash device, after which it can supply
> you with the algorithm, number of pages etc etc.
>
> Best to contact your local Altera or disti FAE for some suggestions.
> 
> Best regards,
> 
> 
> 
> Ben


Article: 108971
Subject: Re: Buffering the critical path.
From: "Marlboro" <ccon67@netscape.net>
Date: 19 Sep 2006 11:05:34 -0700
Links: << >>  << T >>  << A >>
Geezz, doubt if he uses a Xnillix :)

Peter Alfke wrote:
> Vessumesh, if you refuse to answer specific helpful questions, then I
> suggest you figure this out yourself, and do not bother this newsgroup.
> Peter
>
> vssumesh wrote:
> > Peter Alfke wrote:
> > > What kind of device are you using?
> > > 20 ns for a 32-bit adder (using dedicated carry) would be ridiculously
> > > slow...
> > > Dedicated carry, available in all Xilinx FPGA devices, uses less than
> > > 50 ps per bit (plus some basic delay).
> > > Peter Alfke
> > >
> > > ===========
> > > vssumesh wrote:
> > > > Hello all,
> > > >    In my design i am using a 32 bit adder and some combinational logic
> > > > after that. The full path i want to constrain to double the clock
> > > > period (20ns) and it is not constraing. When analysed the critical path
> > > > observed that there is big carry chain for the adder and a big routing
> > > > delay between the combinational logic (which i never expected). Is the
> > > > big carry chain is causing the trouble in the router. I am thinking of
> > > > buffering the output of the adder with a -ve edge (constrain that path
> > > > to 5ns). And then constrain the other path that is after the buffer to
> > > > next stage FF to 16ns. Will this buffering ease the routing effort.
> > > > Please advice.
> > > > Thanks and regards
> > > > Sumesh V S
> > No 20ns for the adder and the remaining combinational logic. The adder
> > delay is as you said is very much less.


Article: 108972
Subject: Re: ddr clock issues
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 19 Sep 2006 18:46:42 GMT
Links: << >>  << T >>  << A >>
David Ashley <dash@nowhere.net.dont.email.me> wrote:

>Open Cores DDR controller uses 2 DCM's to generate the clocks.
>
>clk -> dcm0 -> clock used for fddr to produce true + negative ddr clocks
>                         feedback comes from true ddr clock
>                         fddr has hard wired 01 inputs for true clock,
>                        10 inputs for negative clock
>
>clk -> dcm1 -> (0 clock) bufg1 -> clock used for all ddr related
>internal logic
>                     -> (270 clock) bufg2 -> clock used for fddr's for
>DDR's data in lines
>                      feedback comes from the output of bufg1
>
>
>dcm0 has a tunable parameter, phase shift of 30 ps. I've moved this all
>the way
>to -530ps with no failure. It seems irrelevant.
>
>I want to get rid of one of the DCM's, 2 seems excessive. Is it common
>to use
>an fddr to get a clock to the outside this way? That is, an fddr has

All you need is a normal clock and a 90 degrees phase shifted clock.
The whole clocking outside the fpga thing is unnecessary. If you place
the output flipflops inside the IOBs and use an fddr in the IOB to
replicate the internal clock, all signals connected to the DDR memory
will have the same delay.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108973
Subject: Re: xilinx or altera?
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 19 Sep 2006 12:00:46 -0700
Links: << >>  << T >>  << A >>
Sumesh,

I think that there are a number of folks who post here who provide
hardware.  I am sure they will reply to this posting (after all, they
are in the business of providing pcbs with Xilinx parts on them that do
useful things).

A good inexpensive source is: http://digilentinc.com for the small stuff
(Spartan).

For the bigger parts, there is:

http://www.xilinx.com/xlnx/xebiz/onlinestore.jsp?BV_SessionID=@@@@0352022448.1158692340@@@@&BV_EngineID=cccfaddikmdkkhhcefeceihdffhdfjf.0

(see development boards)

and

Avnet and Nu-Horizons have a ton of pcbs.

Austin

Article: 108974
Subject: Re: E1 to ethernet conversion
From: kicdonc@tiscali.fr
Date: 19 Sep 2006 12:01:41 -0700
Links: << >>  << T >>  << A >>

Symon a =E9crit :

> ITU-T G.703, G.704
> IEEE 802.3
> HTH, Syms
> "sherine" <en.sherine@gmail.com> wrote in message
> news:1158664186.952407.165290@k70g2000cwa.googlegroups.com...
> > hi all, i'm doing a research about " E1 to Ethernet conversion" can any
> > one suggest books or papers to read?? thanks
> >

Hi,

ITU-T G.7043 : Virtual concatenation of plesiochronous digital
hierarchy (PDH) signals;
http://www.itu.int/rec/T-REC-G/en

You can dowload 3 standards for free.




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